设计模式与封装变化
设计模式可以确保系统能以特定方式变化 ( 这很大程度是一种预测 ) ,从而帮助设计者避免重新设计系统。每一个设计模式允许系统结构的某个部分的变化独立于其他部分,这样产生的系统对于某一种特殊变化将更健壮。
下面阐述一些导致重新设计的一般原因,以及解决这些问题的常用设计模式:
1) 通过显式地指定一个类来创建对象。 在创建对象时指定类名 将使设计者受特定实现的约束 , 而不是特定接口 的约束。这会使未来的变化更复杂。要避免这种情况,应该间接地创建对象 。
设计模式: Abstract Factory , Factory Method , Prototype 。
2) 对特殊操作的依赖。 当设计者为请求指定一个特殊操作 时,完成该请求的方式就固定了。避免把请求代码写死,可在编译时刻或运行时刻方便地改变响应请求的方法。
设计模式: Chain of Responsibility (5.1) , Command ( 5 . 2 ) 。
3) 对硬件和软件平台的依赖。 外部的操作系统接口和应用编程接口 (API) 在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上,甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性 就很重要了。
设计模式: Abstract Factory(3.1) , Bridge ( 4 . 2 ) 。
4) 对对象表示或实现的依赖。 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
设计模式: Abstract Factory(3.1) , Bridge ( 4 . 2 ) , Memento ( 5 . 6 ) , Proxy ( 4 . 7 )
5) 算法依赖。 算法在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法 应该被孤立起来。
设计模式: Builder ( 3 . 2 ) , Iterator ( 5 . 4 ) , Strategy ( 5 . 9 ) , Template Method(5.10) ,
Visitor ( 5 . 11 )
6) 紧耦合的类 很难独立地被复用,因为它们是互相依赖的。紧耦合产生单块的系统,要改变或删掉一个类,必须理解和改变其他类。这样的系统是一个很难学习、移植和维护的密集体。
松散耦合 提高了一个类本身被复用的可能性,并且系统更易于学习、移植、修改和扩展。
设计模式使用抽象耦合 和分层技术 来提高系统的松散耦合性。
设计模式: Abstract Factory(3.1) , Command ( 5 . 2 ) , Facade ( 4 . 5 ) , Mediator ( 5 . 5 ) ,
Observer(5.7) , Chain of Responsibility(5.1) 。
7) 通过生成子类来扩充功能。 通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销 ( 初始化、终止处理等 ) 。定义子类还需要对父类有深入的了解。如,重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸,因为即使对于一个简单的扩充,也不得不引入许多新的子类。 ( 本质 : 继承应该仅仅封装一个变化点 )
一般的对象组合技术 和具体的委托技术 ,是继承 之外组合对象行为的另一种灵活方法 。新的功能可以通过以新的方式组合已有对象 ,而不是通过定义已存在类的子类的方式加到应用中去。另一方面,过多使用对象组合会使设计难于理解。许多设计模式产生的设计中,设计者可定义一个子类,且将它的实例和已存在实例进行组合来引入定制的功能。
设计模式: Bridge ( 4 . 2 ) , Chain of Responsibility(5.1) , Composite ( 4 . 3 ) , Decorator ( 4 . 4 ) , Observer (5.7) , Strategy ( 5 . 9 ) 。
8) 不能方便地对类进行修改。 有时设计者不得不改变一个难以修改的类。也许你需要源代码而又没有 ( 对于商业类库 就有这种情况 ) ,或者可能对类的任何改变会要求修改许多 已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法。
设计模式: Adapter ( 4 . 1 ) , Decorator ( 4 . 4 ) , Visitor ( 5 . 11 ) 。
设计模式与其封装的变化点
| 设计模式 | 变化点 |
创建型 | Abstract Factory | 产品对象家族 |
Builder | 组合创建组合 ( 复杂 ) 对象 | |
Factory Method | 被实例化的子类 ( 相关类 ) | |
Prototype | 被实例化的类 | |
Singleton | 一个类的唯一实例 | |
Object Factory | 被实例化的类, Factory Method 的变种 | |
Object Pool | 对象管理和重用, Factory Method 的变种 | |
Creation Method | 类的构造函数, Factory Method 的变种 | |
结构型 | Adapter | 对象的接口 ( 可变 API) |
Bridge | 对象实现 ( 实现逻辑 ) | |
Composite | 对象的结构和组成 | |
Decorator | 对象的职责 ( 职责组合 ) | |
Façade | 子系统的接口 ( 子系统的变化 ) | |
Flyweight | 对象的存储 | |
Proxy | 对象的访问和对象的位置 | |
行为型 | Chain of Responsibility | 满足某个请求的对象 ( 请求的实际处理对象 ) |
Command | 何时、如何实现某个请求 | |
Interpreter | 一个语言的文法和解释 | |
Iterator | 如何遍历、访问一个聚合的各元素 | |
Mediator | 对象间的交互逻辑 | |
Memento | 对象信息的存储管理 | |
Observer | 对象间的依赖和通讯 | |
State | 对象状态 | |
Strategy | 算法 | |
Template Method | 算法某些步骤 | |
Visitor | 作用于对象上的操作 |
待续......