设计原则-原理到实践

设计模式，可以有效的提高软件的可维护性和可复用性，提高开发软件的效率，避免过多的出现再造轮子的现象。

不要想着一下子吃透，学习是一个反反复复的过程：学习原理，实践，再温习，就会有不同的体会或者更深的理解。

理论指导实践。

设计软件的几个原则，这个也是设计模式的精髓所在：

头五项原则是关于类设计的，它们是： 
SRP，单一职责原则，一个类应该有且只有一个改变的理由。 
OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。 
LSP，Liskov替换原则，派生类要与其基类自相容。 
DIP，依赖倒置原则，依赖于抽象而不是实现。 
ISP，接口隔离原则，客户只要关注它们所需的接口。 

另外的六项是关于包的设计原则。

包是指一个二进制的可发布文件，比如.jar文件、或dll文件，而不是Java包或是C++的命名空间。 
头三项包原则是关于包内聚性的，它们会告诉我们该把什么划分到包中： 
REP，重用发布等价原则，重用的粒度就是发布的粒度。 
CCP，共同封闭原则，包中的所有类对于同一类性质的变化应该是共同封闭的。  
CRP，共同重用原则，一个包中的所有类应该是共同重用的。 
最后的三项原则是关于包之间的耦合性原则的，并且论述了评价系统中包结构优良与否的评判标准。 
ADP，无环依赖原则，在包的依赖关系图中不允许存在环。 
SDP，稳定依赖原则，朝着稳定的方向进行依赖。 
SAP，稳定抽象原则，包的抽象程度应该和其稳定程度一致。

 

单一职责原则(SRP)

一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离（MVC设计模式）。

就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的指责.应该把多于的指责分离出去,分别再创建一些类来完成每一个指责.

开闭原则(OCP)
一个软件实体应当对扩展开放，对修改关闭。也就是说，我们在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展，换句话说就是，应当可以在不必修改源代码的情况下改变这个模块的行为。

通过扩展已有的软件系统，可以提供新的行为以满足对软件的新需求，使变化中的软件系统有一定的适应性和灵活性。 
已有的软件模块，特别是最重要的抽象层模块不能再修改，这就使变化中的软件系统有一定的稳定性和延续性。
具有这两个优点的软件系统是一个高层次上实现了复用的系统，也是一个易于维护的系统。

按面向对象的说法，这个就是不允许更改系统的抽象层，而允许扩展的是系统的实现层。

抽象化。让模块依赖于一个固定的抽象体，这样它就是不可以修改的；同时，通过这个抽象体派生，我们就可以扩展此模块的行为功能。如此，这样设计的程序只通过增加代码来变化而不是通过更改现有代码来变化，前面提到的修改的副作用就没有了。

考虑允许什么发生变化而不让这一变化导致重新设计。也就是说，我们要积极的面对变化，积极的包容变化，而不是逃避。 这一思想用一句话总结为：“找到一个系统的可变因素，将它封装起来”，并将它命名为“对可变性的封装原则”。

“对可变性的封装原则”意味者两点：
一种可变性应当被封装到一个对象里面，而不应当散落到代码的很多角落里面。同一种可变性的不同表象意味着同一个继承等级结构中的 具体子类。继承应当被看做是封装变化的方法，而不应当是被认为从一般的对象生成特殊的对象的方法(继承经常被滥用)。
一种可变性不应当与另外一种可变性混合在一起。从具体的类图来看，如果继承结构超过了两层，那么就意味着将两种不同的可变性混合在了一起。

但是现实往往是残酷的，我们不可能100%的遵守OCP，但是我们要向这个目标来靠近。设计者要对设计的模块对何种变化封闭做出选择。

注：不要忘了，设计模式的基础也是抽象 (Astraction)、多态(Polymorphism)、继承(Inheritance)、接口(Interface)
里氏代换原则
在有基类出现的地方，子类均可以替代。
当两个具体类关系违反里氏代换原则时，一种办法是抽象出一个基类，作为这两个类的父类，
一种是应用组合聚合关系建立关系。
不要为了使用某些类的方法（功能）而滥用继承。

依赖倒转原则
抽象不应该依赖与细节，细节应当依赖与抽象。
要针对接口编程，而不是针对实现编程。
传递参数，或者在组合聚合关系中，尽量引用层次高的类。
主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必在弄一个抽象类做它的父类，这样有画舌添足的感觉

接口隔离原则
定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干

迪米特法则（Law of Demeter）

又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD.

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度。

门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。

 

合成/聚合原则
尽量使用合成聚合原则，少用慎用继承。
合成：一荣俱荣，一损俱损，整体和部分的生命周期是一样的
聚合：部分可以是整体的一部分，也可以脱离整体而存在。
继承是强耦合，聚合是弱耦合，所以尽量使用聚合编程，在桥梁模式中，就是使用聚合来代替抽象与具体的强耦合的
区分Has a和Is a的问题