设计模式我从开篇到23种设计模式的讲解总共花了进两个月的时间,其间有很多读者给我提出了很好的建议,同时也指出了我的不足,对此我表示感谢,正是由于很多读者的支持我才能坚持的写到最后.在此表示我真诚的谢意.
系列导航
设计模式原则
使用设计模式的根本原因是适用变化,提高代码复用率,使软件更具有可维护性和可扩展性。需要遵循以下几个原则:单一职责原色、开放封闭原则(Open Closed Principal)、依赖倒置原则、里氏代换原则。
1.单一职责原则
就一个类而言,应该只有一个引起他变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破会。
2.开放封闭原则
软件实体(类、模块、函数等)应该可以扩展,但不可以修改。也就是说对扩展是开放的,对修改是封闭的。一般来说,面对需求,对程序的改动是通过添加新代码进行的,而不是更改现有代码。
3.依赖倒置原则
抽象不应该以来细节,细节应该依赖抽象,也就是提倡的“面对接口编程,而不是面对实现编程”。也可以这样理解:高层模块不应该依赖底层模块,两个都应该抽象;抽象不应该依赖细节,细节应该依赖抽象。
4.里氏代换原则
子类必须能够替换掉他们的父类型。也就是说,在软件开发过程中,子类替换掉父类,程序的功能行为没有变化。只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而子类也可以在父类的基础上增加新的行为。
三种设计模型
创建型模式 1.Singleton模式解决的是实体对象个数的问题。除了Singleton之外,其他创建型模式解决的都是new所带来的耦合关系。
2.Factory Method、Abstract Factory、Builder都需要一个额外的工厂类来负责实例化“易变对象”,而Prototype则是通过原型(一个特殊的工厂类)来克隆“易变对象”。 3.如果遇到“易变类”,起初的设计是从FactoryMethod开始,当遇到更多的复杂变化时,再考虑重构为其他三种工厂模式(Abstract Factory,Builder , Prototype )。结构型模式 1.Adapter模式注重转换接口,将不吻合的接口适配对接
2.Bridge模式注重分离接口与其实现,支持多维度变化 3.Composite模式注重统一接口,将“一对多”的关系转化为“一对一”的关系 4.Decorator模式注重稳定接口,在此前提下为对象扩展功能 5.Facade模式注重简化接口,简化组件系统与外部客户程序的依赖关系 6.Flyweight 模式注重保留接口,在内部使用共享技术对对象存储进行优化 7.Proxy 模式注重假借接口,增加间接层来实现灵活控制行为型模式 1.Template Method模式封装算法结构,支持算法子步骤变化
2.Strategy模式注重封装算法,支持算法的变化 3.State模式注重封装与状态相关的行为,支持状态的变化 4.Memento模式注重封装对象状态变化,支持状态保存/恢复 5.Mediator模式注重封装对象间的交互,支持对象交互的变化6.Chain Of Responsibility模式注重封装对象责任,支持责任的变化
7.Command模式注重将请求封装为对象,支持请求的变化 8.Iterator 模式注重封装集合对象内部结构,支持集合的变化 9.Interpreter模式注重封装特定领域变化,支持领域问题的频繁变化 10.Observer模式注重封装对象通知,支持通信对象的变化 11.Visitor模式注重封装对象操作变化,支持在运行时为类层次结构动态添加新的操作。设计模式应用总结:
1.设计模式建立在对象对系统变化点的基础上进行,哪里有变化点,哪里应用设计模式。
2.设计模式应该以演化的方式来获得,系统的变化点往往是经过不断演化才能精确定位。
3.不能为了模式而模式,设计模式是一种软件设计的软力量,而非规标准,不应夸大设计模式的作用。
各种模式比较
设计模式 | 常用程度 | 适用层次 | 引入时机 | 结构复杂度 |
Abstract Factory | 比较常用 | 应用级 | 设计时 | 比较复杂 |
Builder | 一般 | 代码级 | 编码时 | 一般 |
Factory Method | 很常用 | 代码级 | 编码时 | 简单 |
Prototype | 不太常用 | 应用级 | 编码时、重构时 | 比较简单 |
Singleton | 很常用 | 代码级、应用级 | 设计时、编码时 | 简单 |
Adapter | 一般 | 代码级 | 重构时 | 一般 |
Bridge | 一般 | 代码级 | 设计时、编码时 | 一般 |
Composite | 比较常用 | 代码级 | 编码时、重构时 | 比较复杂 |
Decorator | 一般 | 代码级 | 重构时 | 比较复杂 |
Facade | 很常用 | 应用级、构架级 | 设计时、编码时 | 简单 |
Flyweight | 不太常用 | 代码级、应用级 | 设计时 | 一般 |
Proxy | 比较常用 | 应用级、构架级 | 设计时、编码时 | 简单 |
Chain of Resp. | 不太常用 | 应用级、构架级 | 设计时、编码时 | 比较复杂 |
Command | 比较常用 | 应用级 | 设计时、编码时 | 比较简单 |
Interpreter | 不太常用 | 应用级 | 设计时 | 比较复杂 |
Iterator | 一般 | 代码级、应用级 | 编码时、重构时 | 比较简单 |
Mediator | 一般 | 应用级、构架级 | 编码时、重构时 | 一般 |
Memento | 一般 | 代码级 | 编码时 | 比较简单 |
Observer | 比较常用 | 应用级、构架级 | 设计时、编码时 | 比较简单 |
State | 一般 | 应用级 | 设计时、编码时 | 一般 |
Strategy | 比较常用 | 应用级 | 设计时 | 一般 |
Template Method | 很常用 | 代码级 | 编码时、重构时 | 简单 |
Visitor | 一般 | 应用级 | 设计时 | 比较复杂 |
变化、实现、体现原则
设计模式 | 变化 | 实现 | 体现的原则 |
Abstract Factory | 产品家族的扩展 | 封装产品族系列内容的创建 | 开闭原则 |
Builder | 对象组建的变化 | 封装对象的组建过程 | 开闭原则 |
Factory Method | 子类的实例化 | 对象的创建工作延迟到子类 | 开闭原则 |
Prototype | 实例化的类 | 封装对原型的拷贝 | 依赖倒置原则 |
Singleton | 唯一实例 | 封装对象产生的个数 | |
Adapter | 对象接口的变化 | 接口的转换 | |
Bridge | 对象的多维度变化 | 分离接口以及实现 | 开闭原则 |
Composite | 复杂对象接口的统一 | 统一复杂对象的接口 | 里氏代换原则 |
Decorator | 对象的组合职责 | 在稳定接口上扩展 | 开闭原则 |
Facade | 子系统的高层接口 | 封装子系统 | 开闭原则 |
Flyweight | 系统开销的优化 | 封装对象的获取 | |
Proxy | 对象访问的变化 | 封装对象的访问过程 | 里氏代换原则 |
Chain of Resp. | 对象的请求过程 | 封装对象的责任范围 | |
Command | 请求的变化 | 封装行为对对象 | 开闭原则 |
Interpreter | 领域问题的变化 | 封装特定领域的变化 | |
Iterator | 对象内部集合的变化 | 封装对象内部集合的使用 | 单一职责原则 |
Mediator | 对象交互的变化 | 封装对象间的交互 | 开闭原则 |
Memento | 状态的辅助保存 | 封装对象状态的变化 | 接口隔离原则 |
Observer | 通讯对象的变化 | 封装对象通知 | 开闭原则 |
State | 对象状态的变化 | 封装与状态相关的行为 | 单一职责原则 |
Strategy | 算法的变化 | 封装算法 | 里氏代换原则 |
Template Method | 算法子步骤的变化 | 封装算法结构 | 依赖倒置原则 |
Visitor | 对象操作变化 | 封装对象操作变化 | 开闭原则 |
到这里,设计模式系系就介绍完了,由于我的水平有限,存在失误和不足,欢迎拍砖.