本书上传的所有代码都是可以运行的,在此附上本书源码地址: http://www.ituring.com.cn/book/1811
在此向本书作者和译者表示感谢
Eclipse版本:Oxygen.2 Release (4.7.2)
JDK版本:jdk1.7.0_79
src\com\gdp +---abstractFactory------------------------抽象工厂模式 +---adapter--------------------------------适配器模式 +---bridge---------------------------------桥接模式 +---builder--------------------------------建造者模式 +---chainOfResponsibility------------------职责链模式 +---command--------------------------------命令模式 +---composite------------------------------组合模式 +---decorator------------------------------装饰者模式 +---facade---------------------------------外观模式 +---factoryMethod--------------------------工厂模式 +---flyweight------------------------------享元模式 +---interpreter----------------------------解释器模式 +---iterator-------------------------------迭代模式 +---mediator-------------------------------中介者模式 +---memento--------------------------------备忘录模式 +---observer-------------------------------观察者模式 +---prototype------------------------------原型模式 +---proxy----------------------------------代理模式 +---singleton------------------------------单例模式 +---state----------------------------------状态转换模式 +---strategy-------------------------------策略模式 +---templateMethod-------------------------模版模式 +---visitor--------------------------------访问者模式 images-------------------------------------运行结果截图 static-------------------------------------程序中需要用到的静态资源(程序中已经写好读取路径)
使用继承的示例
使用委托的示例
习题2-2:修改了适配器代码,可以打印出新的文件
- Iterator模式:遍历与实现分离,遍历的时候不依赖实现。
- Adapter模式:版本升级和兼容性,现有的类已经被测试过,创建一个新类来适配,只需要测试新类,如果出现了Bug,可以很容易的知道问题所在。
- Template Method模式:在父类中定义处理流程的框架,在子类中实现具体处理,避开使用instanceof指定子类。
- Factory Method模式:框架与具体加工分离。
- Singleton模式:获取唯一一个实例(延迟加载,同步机制)。
- Prototype模式:根据实例(实例原型、实例模型)来生成新实例。
- Builder模式:可替换性,可以替换Builder组件类。
- Abstract Factory模式:易于增加具体工厂,难以增加新的零件。
- Bridge模式:将类的功能层次和实现层次分开。继承是强关联,委托是弱关联。
- Strategy模式:使用委托这种弱关联关系可以很方便地整体替换算法。
- Composite模式:容器和内容具有一致性,并且可以创建出递归结构。
- Decorator模式:不修改被装饰的类即可增加功能,缺点是会导致程序中增加许多功能类似的很小的类
- Visitor模式:双重分发,将处理从数据结构中分离出来。缺点是将来对数据结构的改良就会变得非常困难。
- Chain of Responsibility模式:弱化了发出请求的人和处理请求的人之间的关系,缺点是导致处理请求发生了延迟。
- Facade模式:优点是接口(API)变少了,程序与外部的关联关系弱化了。
- Mediator模式:不让互相关联的对象之间进行任何直接的通信,而是让它们向仲裁者进行报告。
- Observer模式:将对象的状态变化通知给其他对象。
- Memento模式:具有SRP(单一权责),记录和保存对象的当前状态。
- State模式:分而治之,缺点是每个ConcreateState角色都需要知道娶她ConcreateState角色。
- Flyweight模式:共享实例减少内存使用量,线程池或者各种缓存技术(Memcached,Redis)。
- Proxy模式:Virtual Proxy(虚拟代理:真正需要实例时才生成和初始化实例),Remote Proxy(远程代理:RMI),Access Proxy(访问限制:CAS)
- Command模式:用对象表示 “ 命令 ”来保存命令历史记录和重复执行命令。
- Interpreter模式:使用BNF递归定义语言的方法和推导语法树。
- 这些模式都是对接口或者抽象类编程,关于如何选择接口或者抽象类主要是(1)如果想支持并设计模版,可以用抽象类来实现。(2)如果想实现多重继承,那么你必须使用接口。(3)如果基本功能在不断改变,那么就需要使用抽象类。如果不断改变基本功能并且使用接口,那么就需要改变所有实现了该接口的类。
- 本书中对模式的分类也十分合理:(1)适应设计模式:Iterator,Adapter;(2)交给子类:Template Method,Factory Method;(3)生成实例:Singleton,Prototype,Builder,Abstract Factory;(4)分开考虑:Bridge,Strategy;(5)一致性:Composite,Decorator;(6)访问数据结构:Visitor,Chain of Responsibility;(7)简单化:Facade,Mediator;(8)管理状态:Observer,Memento,State;(9)避免浪费:Flyweight,Proxy;(10)用类来表现:Command,Interpreter。通过对各种模式的特性分类,而GOF中的分类总是让人有点记不住。
- 有空想用Interpreter模式(Java版本)来实现Lisp的解释器,可参考Build-Your-Own-Lisp,GitHub地址:https://github.com/orangeduck/BuildYourOwnLisp,目前有一个不全的中文翻译版本,GitHub地址如下:https://github.com/ksco/BuildYourOwnLispCn,笔者已经联系了该文译者,有幸参与该书剩下几章内容的翻译。完成之后经过译者同意会发布出来。