# 16.9 总结 从表面看，由于象`TrashVisitor.java`这样的设计包含了比早期设计数量更多的代码，所以会留下效率不高的印象。试图用各种设计模式达到什么目的应该是我们考虑的重点。设计模式特别适合“将发生变化的东西与保持不变的东西隔离开”。而“发生变化的东西”可以代表许多种变化。之所以发生变化，可能是由于程序进入一个新环境，或者由于当前环境的一些东西发生了变化（例如“用户希望在屏幕上当前显示的图示中添加一种新的几何形状”）。或者就象本章描述的那样，变化可能是对代码主体的不断改进。尽管废品分类以前的例子强调了新型`Trash`向系统的加入，但`TrashVisitor.java`允许我们方便地添加新功能，同时不会对`Trash`结构造成干扰。`TrashVisitor.java`里确实多出了许多代码，但在`Visitor`里添加新功能只需要极小的代价。如果经常都要进行此类活动，那么多一些代码也是值得的。 变化序列的发现并非一件平常事；在程序的初始设计出台以前，那些分析家一般不可能预测到这种变化。除非进入项目设计的后期，否则一些必要的信息是不会显露出来的：有时只有进入设计或最终实现阶段，才能体会到对自己系统一个更深入或更不易察觉需要。添加新类型时（这是“回收”例子最主要的一个重点），可能会意识到只有自己进入维护阶段，而且开始扩充系统时，才需要一个特定的继承结构。 通过设计模式的学习，大家可体会到最重要的一件事情就是本书一直宣扬的一个观点——多态性是OOP（面向对象程序设计）的全部——已发生了彻底的改变。换句话说，很难“获得”多态性；而一旦获得，就需要尝试将自己的所有设计都转换到一个特定的模子里去。 设计模式要表明的观点是“OOP并不仅仅同多态性有关”。应当与OOP有关的是“将发生变化的东西同保持不变的东西分隔开来”。多态性是达到这一目的的特别重要的手段。而且假如编程语言直接支持多态性，那么它就显得尤其有用（由于直接支持，所以不必自己动手编写，从而节省大量的精力和时间）。但设计模式向我们揭示的却是达到基本目标的另一些常规途径。而且一旦熟悉并掌握了它的用法，就会发现自己可以做出更有创新性的设计。 由于《设计模式》这本书对程序员造成了如此重要的影响，所以他们纷纷开始寻找其他模式。随着的时间的推移，这类模式必然会越来越多。JimCoplien（`http://www.bell-labs.com/~cope` 主页作者）向我们推荐了这样的一些站点，上面有许多很有价值的模式说明： http://st-www.cs.uiuc.edu/users/patterns http://c2.com/cgi/wiki http://c2.com/ppr http://www.bell-labs.com/people/cope/Patterns/Process/index.html http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns http://st-www.cs.uiuc.edu/cgi-bin/wikic/wikic http://www.cs.wustl.edu/~schmidt/patterns.html http://www.espinc.com/patterns/overview.html 同时请留意每年都要召开一届权威性的设计模式会议，名为PLOP。会议会出版许多学术论文，第三届已在1997年底召开过了，会议所有资料均由Addison-Wesley出版。