将枚举器适配到迭代器：
public class EnumerationIterator implements Iterator {
/*
* 因为我们将枚举适配成迭代器，适配器需要实现迭代器接口，适配器必须看起来就像是一个迭代器
* 我们利用组合的方式，将枚举结合进入适配器中，所以用一个实例变量记录枚举
*/
Enumeration enumeration;
public EnumerationIterator(Enumeration enumeration) {
this.enumeration = enumeration;
}
//迭代器的hasNext()方法其实是委托给枚举的hasMoreElements()方法
public boolean hasNext() {
return enumeration.hasMoreElements();
}
//next()委托给nextElements()方法
public Object next() {
return enumeration.nextElement();
}
//很不幸，我们不能支持迭代器的remove()方法，所以必须放弃，我们的做法是抛出一个异常
public void remove() {
throw new UnsupportedOperationException();
}
}
2.6 外观模式（Facade Pattern）
外观不只是简化了接口，也将客户从 组件的子 系统中解耦。 外观和适配器可以包装许多类，但是外观的意图是简化接口。而适配器的意图是将接口转换成不同的接口。
构造家庭影院外观，代码比较多就不贴了，类的主要功能是将子系统的实例引入家庭影院HomeTheaterFacade。
实现简化的接口
public void watchMovie(String movie) {
/*
* watchMovie()将我们之前手动进行的每项任务依次处理。请注意，每项任务都是
* 委托子系统中相应的组件处理的。
*/
System.out.println("Get ready to watch a movie...");
popper.on();
popper.pop();
lights.dim(10);
screen.down();
projector.on();
projector.wideScreenMode();
amp.on();
amp.setDvd(dvd);
amp.setSurroundSound();
amp.setVolume(5);
dvd.on();
dvd.play(movie);
}
外观模式：提供了一个统一的接口，用来访问子系统中的一群接口。外观定义了一个高层接口，让子系统更容易使用。 最少知识原则：只和你最亲密的朋友谈话。 当你正在设计一个系统时，不管是任何对象，你都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。 这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。如果许多类之间相互依赖，那么这个系统就会变成一个易碎的系统，它需要花很多成本维护，也会因为太复杂而不容易被其他人了解。
究竟要怎么样才能避免这样呢？这个原则提供了一些方针：就任何对象而言，在该对象的方法内，我们只应该调用属于以下范围的方法： 1、该对象本身 2、被当做方法（包括构造器）的参数而传递进来的对象 3、此方法所创建或实例化的任何对象 4、对象的任何组件
这听起来有点严厉，不是吗？如果调用从另一个调用中返回的对象的方法，会有什么害处呢？如果我们这样做，相当于向另一个对象的子部分发请求（而增加我们直接认识的对象数目）。在这种情况下，原则要我们改为要求该对象为我们做出请求，这么一来，我们就不需要认识该对象的组件。
3 本章小结
这两个模式在我们编码过程中其实已经有意无意的用到过，比如xml转换成json，中间会有很多对象方法，最后封装之后只有一个xmlToJson（）方法就搞定了，这个就是外观模式，再比如serverlet里面的http类，通过将二进制流转换成文本流，方便我们直接获取其中的文本信息。 先行者总结，学好设计模式不一定能写出好看的代码，不学设计模式不一定写不出好看的代码。设计模式其实是贯穿整个编码过程中，有些模式潜移默化的影响着我们的编码习惯，多总结，多实践，在通往架构师的道路上努力前进。