Proxy 模式和权限控制 Proxy 模式的功能有很多，比如远程代理，用来给远程对象提供一个本地代表；虚代理，用来为创建开大开销的对象提供缓冲，等等。在 Jive 中使用的是保护代理，为被保护的对象提供权限控制。
我们都知道在一个论坛中，权限的控制是必须的，否则论坛就很可能会被搞得一团糟。Jive 中引入 Proxy 对象，Authorization 接口以及权限描叙属类来提供对论坛的保护。
以 ForumFactory 为例，一个额外的 ForumFactoryProxy 来处理权限认证的工作，它为某一个 ForumFactory 提供了一个代理，保证只有授权的用户才能够存取 ForumFactory 的某些操作。实际上 ForumFactory 在这儿不仅仅只是一个生成 Forum 的类的，它更像是一个 Forum 的管理类。提供了添加，删除，枚举等等一系列的功能，而有些功能不是什么样的人都可以使用的，因而引入了另外的一个代理类来处理权限的问题。
当然，代理类需要继承 ForumFactory，以使方法签名一致： ForumFactoryProxy extends ForumFactory
在它的构造方法中，就提供了一个 ForumFactory 对象，这是需要被代理的对象；一个 Authorization 对象，提供用户信息；还有一个 ForumPermissions，提供认证信息：
1
2
3
4
5
6
7
| public ForumFactoryProxy(ForumFactory factory, Authorization authorization,
ForumPermissions permissions)
{
this.factory = factory;
this.authorization = authorization;
this.permissions = permissions;
}
|
一般的代理过程都是这样的，在访问某个方法之前，必须接受权限的检查，以 createForum 为例：
1
2
3
4
5
6
7
8
9
10
11
| public Forum createForum(String name, String description)
throws UnauthorizedException, ForumAlreadyExistsException
{
if (permissions.get(ForumPermissions.SYSTEM_ADMIN)) {
Forum newForum = factory.createForum(name, description);
return new ForumProxy(newForum, authorization, permissions);
}
else {
throw new UnauthorizedException();
}
}
|
下面给出这个模式的类图：
图 3：Proxy 模式的类图 这个模式的实现基本上和 GOF 中所给出的实现一致。在 Jive 中，几乎所有的接口，Forum，ForumMessage，ForumThread 等等，都会有一个相应的 Proxy 对象来进行权限控制。而在创建具体的对象的时候，都是用相应的 Proxy 对象来代替原有的对象返回的。例如在 ForumFactory 的 getInstance() 方法中需要返回一个 Forum 的时候，Jive 是这样做的：
1
2
3
4
5
6
| public static ForumFactory getInstance(Authorization authorization) {
......
ForumFactoryProxy proxy = new ForumFactoryProxy(factory,authorization,
factory.getPermissions(authorization));
return proxy;
}
|
因而，所有被创建的对象实际上都是 Proxy 对象，抽象工厂保证了没有权限验证的对象根本不会客户所得到，它们只会在 Proxy 的内部扮演角色，而永远不会被外部对象所存取，这样，就从根本上保证了论坛的安全。
Decorator 模式和过滤器一般的在 OO 设计中，而外功能的添加是通过继承来实现的，但是继承有的时候不够灵活，而且当功能的组合很多的时候，继承的子类就会成几何级数增长，使得类多的难以控制。正是基于这样的考虑，Decorator 模式得以诞生。
Decorator 模式相当于封装了某个特定的操作，当某个对象需要这个操作的时候，加上这个 Decorator 即可。并且，多个 Decorator 还可以组合，以提供更多的功能。
在 Jive 中，Decorator 模式应用在一些过滤器（Filter）中。Filter 提供对 ForumMessage 对象内容的重新构造。比如，当一个 ForumMessage 对象流过一个名为 FilterCodeHighlight 的过滤器后，存在于消息中的所有 Java 源代码文本，会被重新构造为具有语法高亮显示的消息。在比如，当经过了语法高亮修饰的消息再流过一个名为 FilterHtml 的过滤器后，消息中的 HTML 片断会被注释可以在 HTML 内部显示文本，这样就防止了用户输入了 HTML 控制标签后，使得页面显示不正常的问题。
Jive 中，所有的过滤器继承于一个抽象类 ForumMessageFilter，而 ForumMessageFilter 又实现了 ForumMessage 接口。也就是说，每一个过滤器实际上也是一个 ForumMessage 对象。
ForumMessageFilter 中还封装一个 ForumMessage 对象。进行过滤的方法很简单，使用的是 getBody()，比如在 FilterCodeHighlight 这个类中：
1
2
3
| public String getBody() {
return highlightCode(message.getBody());
}
|
highlightCode 是一个 private 方法，实施具体的过滤的细节。getBody() 方法实际上是定义在 ForumMessage 接口中的，当调用过滤器的 getBody() 方法时，就能够得到结构重整后的 ForumMessage 对象了。这个对象可以被其他客户引用，也可以在传递给另外的过滤器，实施进一步的操作。
在实现一个具体的消息的过滤的时候，在 Forum 中有 addForumMessageFilter()，applyFilters() 方法，用来实现对过滤器的应用。
对一个 Forum，使用 addForumMessageFilter() 方法添加一个 Filter 的时候，并没有指定一个具体的 Message，而只是一个规则（Filter 中封装了过滤规则），然后 applyFilter() 方法中，实施这些规则：
1
2
3
4
5
6
7
| public ForumMessage applyFilters(ForumMessage message) {
//Loop through filters and apply them
for (int i=0; i < filters.length; i++) {
message = filters.clone(message);
}
return message;
}
|
过滤器的 clone() 方法，为过滤器复制消息体。这个方法的使用，分离了在过滤器中对于消息体和过滤规则的初始化过程，这也是一个值得借鉴的技巧！
下面给出 Decorator 模式的类图 :
图 4：Decorator 模式的类图 我们可以看到 Decorator 模式实际上和 Proxy 模式是很相近的，但是它们代表两个不同的功能含义。Proxy 模式提供一个对象的控制，而 Decorator 模式则是为对象提供额外的功能。
Iterator 模式和论坛的浏览 Iterator 模式用来分离数据结构和遍历算法，降低两者之间的耦合度，以使得同一个数据结构用不同的算法遍历时，仍能够具有相同的接口，另一方面，Iterator 模式使得当改换遍历算法后，不需要更改程序的代码。
在 Java 的 JDK 中本身就定义有一个 Iterator 接口，在 Iterator 接口中仅仅定义了三个方法，hasNext() 判断是否遍历完最后一个元素，next() 方法返回要遍历的数据结构中一个对象，remove() 则删除当前对象。Jive 中使用 IteratorProxy 抽象类继承了这一接口。这儿 Proxy 的含义和上面一样，也就是说，这个 IteratorProxy 出了会实现 Iterator 的遍历功能外，还会有代理权限控制的功能。
对于论坛中的基本对象 Forum，ForumThread，ForumMessage，Group，User 都有相应的遍历器。比如对应于 Forum 接口有 ForumIteratorProxy 对象。这个 ForumIteratorProxy 遍历器就相当于一个封装了一系列 Forum 对象的集合类，通过定义好的接口 hasNext() 和 next() 可以方便的遍历这个集合，而并不需要知道是如何遍历这个集合的。遍历的算法可能很简单，也可能很复杂，但是对于外部的客户而言，这并没有任何的区别。
而对于论坛中具体的遍历方法，这取决于具体的实现，在 Jive 中给出的是数据库的实现。
我们就以 MessageIteratorProxy 为例，来讲解 Iterator 模式的用法。
DbThreadIterator 对象实现了 Iterator 接口，是对于一个 Thread 中所有 Message 的遍历器，我们来看看它是如何实现的。
hasNext() 判断在这个 Thread 中是不是还有下一条 Message：
1
2
3
4
5
6
| public boolean hasNext() {
if (currentIndex+1 >= messages.length) {
return false;
}
return true;
}
|
next() 方法从数据库中取出与在这个 Thread 中的下一条 Message：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| public Object next() throws java.util.NoSuchElementException {
ForumMessage message = null;
if (nextMessage != null) {
message = nextMessage;
nextMessage = null;
}
else {
message = getNextMessage();
if (message == null) {
throw new java.util.NoSuchElementException();
}
}
return message;
}
|
这样，通过对数据库的操作，DbThreadIterator 实现了对一个 Thread 中所有 Message 遍历的方法。
再 ForumThread 接口中有 messages() 方法，返回在这个 Thread 中的所有 Message 的一个遍历器（Iterator），实际上也就是返回了一个 Message 的集合：
public Iterator messages();
在 DbForumThread 中实现了这个方法：
public Iterator messages() {return new DbThreadIterator(this);}
从 DbForumThread 的 messages() 方法中所返回的就是这个 Thread 中所有 Message 的一个遍历器，通过这个遍历器，我们就可以访问 Thread 中的所有的 Message 了。当然，事情还没有完，由于权限的问题，我们还需要构造这个遍历器的 Proxy 对象，然后通过这个 Proxy 对象来访问遍历器。
下面的类图给出了在 Jive 中 Iterator 模式的实现方法：
图 5：Jive 中 Iterator 模式的实现 在 Jive 中，因为在一个 Thread 之下，Message 是按树形结构组织的，因而，当需要层级表示一个 Thread 中的 Message 之间的关系的时候，仅仅用上面讲到的线性的 Iterator 是不够的。这时候，对 Iterator 的概念进行推广，就引入了 TreeWalker 接口。
顾名思义，TreeWalker 提供了遍历一个树和存取树上节点的方法：
1
2
3
4
5
6
7
| public interface TreeWalker {
public ForumMessage getRoot();
public ForumMessage getChild(ForumMessage parent, int index);
public int getChildCount(ForumMessage parent);
public int getRecursiveChildCount(ForumMessage parent);
public int getIndexOfChild(ForumMessage parent, ForumMessage child);
public boolean isLeaf(ForumMessage node);
|
TreeWalker 只是 Iterator 的简单推广，并没有 Iterator 应用的那么广泛，而且，也可以很容易的在 TreeWalker 上面在套一层 Iterator 的借口，让它在某些情况下行使 Iterator 的职责。这儿就不再多讨论了。
再此，Jive 设计中所有涉及到的设计模式的地方，基本上都讲完了，看完了之后，是不是对设计模式有了更进一步的了解了呢？ |
