设计模式学习小结

这段时间重新翻看了一下阎宏的《Java与模式》，把里面我敢兴趣的地方摘抄与此。
首先

Gof 写道

本书中的设计模式是对被用来在特定场景下解决一般设计问题的类和相互通信的对象的描述。

一.面向对象软件设计的核心问题：可维护性(Maintainability)与可复用性(Reuseability)。

二.维护性较差的原因：
过于僵硬 Rigidity   <---> 可扩展性 Extensibility
过于脆弱 Fragility  <---> 灵活性   Flexibility
复用率低 Immobility
粘度过高 Viscosity  <---> 可插入性 Pluggability

三.面向对象设计的几个原则
开-闭原则         Open-Closed Principle              OCP
里氏代换原则      Liskov Substitution Principle      LSP
依赖倒转原则      Dependency Inversion Principle     DIP
接口隔离原则      Interface Segregation Principle    ISP
组合/聚合复用原则 Composition/Aggregation Principle  CARP
迪米特法则        Law of Demeter                     LoD
可扩展性：OCP, LSP, DIP,CARP
灵活性：OCP, ISP,LoD
以上两点的交集就是&ldquo;可维护性复用&rdquo;。

1.开闭原则 OCP
一个软件的实体应当对扩展开放，对修改关闭。
Software entities should be open for extension,but closed for modification.

对可变性的封装原则 Principle of Encapsulation of Variation   EVP
EVP实际上是设计模式的主题，换言之，所有的设计模式都是对不同的可变性的封装，从而使系统在不同的角度上达到OCP要求。

2.里氏代换原则 LSP
如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有对象o1都代换成o2时，程序P的行为没有变化，那么类型T2是T1的子类型。
LSP要求凡是基类使用的地方，子类型一定适用。
LSP是一条非常严格的原则，要求基类变为子类的时候，其程序行为不发生改变。在oop时并没有严格按照LSP来做。

3.依赖倒转原则 DIP
表述1：抽象不应当依赖于细节，细节应当依赖于抽象。
       Abstractions should not depend upon details, details should depend upon abstractions.
表述2：要针对接口编程，不要针对实现编程。
       Program to an interface, not an implementation.

4.接口隔离原则 ISP
使用多个专门的接口比使用单一的总接口要好。
一个类对另一个类的依赖性应当是建立在最小接口上的(LoD)。

5.合成/聚合复用原则 CARP
= 合成复用原则 Composite Reuse Principle CRP
要尽量使用合成/聚合，尽量不要使用继承。
继承的优点：①新类易实现. ②易修改或扩展
      缺点：①继承复用破环包装，白箱复用.
            ②超类发生变化，子类不得不改变.
            ③继承的实现是静态的，不能在运行时改变.
优缺点的②是相互对应的。

6.迪米特法则 LoD
= 最少知识原则 Least Konwledge Principle
一个对象应当对其他对象有尽可能少的了解。
表述：
①只与你直接的朋友们通信 Only talk to your immediate friends
②不要跟陌生人说话 Don's talk to strangers
③每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。
LoD的实质是控制对象之间的信息流量，流向及信息的影响。
①优先考虑将一个类设置成不变类.
②尽量降低类/成员的访问权限.

要想恰到好处地在一个系统里面使用设计模式，必须做到以下几点：
①完全了解面临的问题，这就是说要完全了解具体情况。如果不完全了解所面临的难题，怎么能谈得上解决问题呢？
②完全了解模式，这就是说要十分懂得理论。如果不完全懂得所使用的理论，怎么能够正确地应用这一理论呢？
③非常了解怎样使用设计模式解决实际的问题，这就是说要将模式理论与具体系统需求情况相结合。如果设计师不知道一个设计模式怎样对系统设计有帮组的话，最好不要使用这个模式。不要只是因为想在简历上写上设计模式方面的经验就盲目地使用模式。

来看看gof是怎么说的

Gof 写道

通常你通过引入额外的间接层获得灵活性和可变性的同时，你也使设计变得更复杂并/或牺牲了一定的性能。一个设计模式只有当它提供的灵活性是真正需要的时候，才有必要使用。

写在最后
原本想写个总结什么的，写写各种模式的设计，再举个简单例子什么的。最后大感不必（神啊！原谅我的懒惰吧！）在这次翻看设计模式时，最大的感受是&ldquo;万变不离其中&rdquo;。很多设计模式在设计时都遵循上面列举的几个原则，不同的模式对原则有不同的侧重，在学习时可以运用这些原则去分析这些既有的设计模式，判断它们的优缺点。进而提高自己的分析和设计能力，毕竟GOF的23种设计模式也有它的局限，总会有新的问题待自己去解决。再说设计模式本身也不是语言中立的，先不提OOP与FP，就连OOP之间，有些设计模式就不是互通的，当然这些都是题外话了。
最后总结一下自己学习设计模式的阶段过程：
GOF---> Java与模式 ---> 面向对象设计的基本原则 ---> 用原则自行分析既有设计模式 ---> 忘掉设计模式！ ---> 开始动手干！
最后带！号的阶段还没有开始处于&ldquo;意淫&rdquo;阶段，不过当当&ldquo;自淫者&rdquo;也不妨，别怕失败，工资是靠失败积累起来地！