设计模式感悟(部分)

模式的法律（面向对象设计的基础准则）

• 对“多变”的部分进行封装
• 尽量使用“组合”而少用“继承”
• 面向“接口”编程，而非面向“实现”
• 对象间的交互行为要尽可能“松耦合”设计
• 类要对“扩展”开放，对“修改”关闭
• 依赖“抽象”而不依赖具的类
• 只和朋友交谈（不要通过A类去获取B类并访问它）
• 等我的电话，别打给我
• 一个类只应该有一个改变的理由（一个类只应给关注一个功能面）

策略模式 

• 定义了一系列的算法，分别分装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户。
• 封装可以互换的行为，并使用委托来决定要使用哪一个。
• 配合Spring 的IOC配置，真是相得益彰啊

观察者模式

• 定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新。
• 让对象能够在状态改变时被通知。
• 典型的例子如，swing中的listener设计
• 其实，被观察者也可以是一系列的类，有自己的接口

装饰着模式

• 动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案
• 装修器通常实现一个接口，并同时持有实现这个接口的另一个实现类的实例。
• 封装一个对象，以提供新的行为。
• 非常熟悉的例子就是Java 的IO包中的InputStream和OuputStream

工厂模式

• 定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
• 由子类决定要创建的具体类是哪一个。
• 最常见的就是common logging中的LogFactory了

抽象工厂模式

• 提供一个接口，用于创建相关或依赖对象的家族，而不需要明确指定具体类。
• 允许客户创建对象的家族，而无需指定它们的具体类。

单例模式

• 确保一个类只有一个实例，并提供一个全局访问点。
• 确保有且只有一个对象被创建
• 貌似谁都会写的模式，也最容易理解，其实不然，注意单例在多线程环境下的使用

命令模式

• 将请求封装成一个对象（通常会带上请求的执行者一并封装），以便使用不同的请求、队列或者日志来参数化其他对象。
• 传说是可以执行UNDO的操作。
• 有了它还可以实现任务调度哦（优先级、定时执行）。

适配器模式

• 将一个类的接口、转换成客户期望的另一个接口。
• Java只支持对象适配，不支持类适配，因为没有多重继承啊
• 看看swing中对listener接口的adapter实现的种种吧，感觉这个模式很好理解

外观模式

• 也叫做“门面模式”，提供一个统一的接口，用来访问子系统中的一群接口。它提供了系统的一个高层接口，让子系统更容易使用。
• 简化一群类的接口（将一系列的调用封装成一个调用，有点像“宏”或者批处理的概念）
• 实际上就是OO设计中谈到的“封装”，这个模式实际上，我们经常会不自觉的使用上，最不用学习的一个模式。

模板模式

• 在一个方法中定义一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下，重新定义算法中的某些步骤。
• 由子类决定如何实现一个算法中的步骤。
• 知道C/C++中的钩子嘛，就是用这种模式实现的，很神奇的一个模式哦。加上用配置变量控制钩子，真是变化无穷啊。威力强大！！！
• Java集合框架中的比较算法（equals，hashCode, compareTo）用得就是模板模式

迭代器模式

• 提供一种方法，顺序访问一个聚合中的各个元素，而不暴露集合的实现。
• java.util.Iterator闻名天下啊，没啥好多说的了

组合模式

• 允许你将对象组合成树型结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。
• 窗体组件渲染基本都好似用这种模式。
• 组合模式是递归的一种结构化表示。

状态模式

• 允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类。
• 封装了基于状态的行为，并使用“委托对象”在行为之间切换。
• 这是状态机理论的OO化表现。

代理模式

• 为另一个对象提供一个替身或占位符以控制对对象的访问。
• EJB ，RMI 的stub ，Hibernate中的延迟加载，Spring中的AOP，proxy在我们的周围比比皆是啊，包装对象，以控制对此对象的访问是这个模式最吸引人的地方。
• 看过电影《机器化身》嘛，不理解这个模式的话，看过这部电影就知道了，哈哈。

责任链模式

• 将对同一请求的多个处理分散在不同对象上。
• 用过servlet的filter嘛，典型的Chain of Responsibility。这个模式有点像公文审批流程，哈哈。