DP23一瞥 ---- 讲座素材

 

OO目标

问题所在 设计目标
----------------------------------------------------
过于僵硬 可扩展性（新性能可以很容易加入系统）
过于脆弱 灵活性（修改不会波及其它）
复用率低
粘度过高 可插入性（新功能容易加入系统（气囊加入方向盘））

 

OO原则

Open-Closed Principle原则讲的是：一个软件实体应当对扩展开放，对修改关闭。

（玉帝招安美猴王，宪法和基它法）

Liskov Substitution Principle（里氏代换原则）：子类型(subtype)必须能够替换它们的基类型。

(墨子兼爱与爱“女朋友”，“娣，美人也，爱娣，非爱美人也……”)

依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。

（电器与插座设计）

接口隔离原则（Interface Segregation Principle）讲的是：使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。接口应面向用户。

（电器基于插头接口和变压，而不是通电接口）

合成/聚合复用原则（Composite/Aggregate Reuse Principle或CARP），简而言之，要尽量使用合成/聚合，尽量不要使用继承。

（汽车通过聚合车轮得到移动功能，而不是通过继承来获得

）

迪米特法则（Law of Demeter或简写LoD）又叫最少知识原则（Least Knowledge Principle或简写为LKP），也就是说，一个对象应当对其它对象有尽可能少的了解。

(《老子》第三章曰："是以圣人之治，虚其心，实其腹，弱其志，常使民无知无欲。"使被"统治"的对象"愚昧"化，处于"无知"的状态，可以使"统治"的成本降低。

《老子》云："小国寡民……邻国相望，鸡犬之声相闻，民至老死，不相往来。"将被统治的对象隔离开来，使它们没有直接的通信，可以达到分化瓦解，继而分而治之的效果。)

 

DP23

创建型模式

1. 单件Singleton模式要求一个类有且仅有一个实例，并且提供了一个全局的访问点(美国总统，全校的班级集合)

2. 抽象工厂AbstractFactory模式/工厂模式 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类（冲压机床，Array.CreateInstance(),WebRequest.Create()）

3. 建造者模式（Builder Pattern）在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定（KFC/StringBuilder/邮局包裹）

结构型模式篇

4. 原型模式（Prototype Pattern）用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 (javascript function)

5. 适配器模式（Adapter Pattern）将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。(音频线转接头，DataAdapter把DataReader变成了DataSet)

6. 桥接模式（Bridge Pattern）将抽象部分与实现部分分离，使它们都可以独立的变化（电器的开关是实现部分，其它部分是抽象的,ASP.NET Ajax中的asbx文件）

7. 装饰模式（Decorator Pattern）动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。（“子类复子类，子类何其多”，变继承为聚合，比如BufferedStream与FileStream）。（Bitmap和Image）

8. 组合模式（Composite Pattern）将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。（Control的呈现，在调用一个控件的呈现时，不管这个控件是孤零零的，还是有很多子控件，都是一样的）

9. 外观模式（Façade Pattern）在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用（SqlHelper，隐藏内部细节）

10. 享元模式（Flyweight Pattern）对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作？Flyweight在拳击比赛中指最轻量级，即“蝇量级”，这里翻译为“享元”，可以理解为共享元对象（细粒度对象）的意思。（word在处理字符的时候，不是为每一个字符保存字体颜色等信息的，而是一片字符共用同样的设置，代码实现可以默认继承前面的字符）

11. 代理模式（Proxy Pattern） ASP.NET Ajax中的WebService代理，Remoting中的透明代理

行为型模式篇

12. 模板Template Method模式如果你只想掌握一种设计模式的话，那这个模式一定是Template Method模式(抽象类就是模板、图铃查询界面，ITemplate)

13. 命令模式（Command Pattern）Command模式将一个请求封装为一个对象，从而使你可以使用不同的请求对客户进行参数化。（用餐时的账单，叫菜本来只是一个命令，被特立出一个类，SqlCommand，SqlDataAdapter对SqlCommand的使用，先封装好了命令，需要的时候再调用）。

14. 迭代器模式（Iterator Pattern）Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。（IEnumerator）(foreach对不同的集合都可很好的支持)

15. 观察者模式（Observer Pattern）定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新（拍卖师，事件和委托）

16. 中介者模式（Mediator Pattern） 中介者包装一系列对象相互作用的方式，使对象之间不必互相明显的引用。（房屋中介，对双方提供更友好的接口）

17. 备忘录模式（Memento Pattern）备忘录对象存储另一个对象的内部状态。（windows的备份，DataTable的RowVersion）

18. 状态模式（State Pattern） 状态发生改变，其行为也发生改变（男人和女人，可以是两个不同的类，也可以是一个类的某个状态不同，所以穿衣的行为就不同） WorkFlow的状态机

19. 解释器模式（Interpreter Pattern）定义一种文法，并提供解释器（比如正则表达式）

20. 策略模式（Strategy Pattern）策略模式的用意是针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。(控件的生命周期)

21. 职责链模式（Chain of Responsibility）在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。（审批过程组长到经理到校长，Remoting中的MessageSink）

22. 访问者模式（Visitor Pattern）访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。一旦这些操作需要修改的话，接受这个操作的数据结构则可以保持不变，它把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由地演化。（简单说就是主人不动，客人来送礼）

23.不变(Immutable)模式 对象的状态在创建后就不再变化。(人的年龄可变，生日不可变，string的不可变)