面向对象软件设计原则

1、 开放-封闭原则（OCP：Open-Closed Principle）： Software entities should be open for extension, but closed for modification.通俗地说就是， 开发一个软件时，应该可以对它进行扩展（开放），而在进行这些扩展的时候，不需要对原来的程序进行修改（关闭）。 
       目前 ， 对于OCP的实现，主要就是抽象。 把系统 所有可能的行为抽象成一个抽象底层 ，这个抽象底层规定出所有的具体类必须提供方法的特征，这个抽象层要预见所有可能的扩展，从而使得在任何扩展情况下，系统的抽象层不需修改，同时由于可以从抽象层导出一个或多个新的具体类来改变系统的行为，因此对于可变的部分，系统设计对扩展是开放的。
       对于OCP，在工程上被描述成“可变性封装原则”，就是把系统的可变性封装起来，这就意味着：
       ①一种可变性不应该散落在软件的各个角落，而应该把它封装成一个对象；
       ② 一种可变性不应该和别的可变性混淆在一起。

2、单一职责原则（SRP：Single Responsibility Principle）： 对一个类而言，应该仅有一个引起它变化的原因。如果有多于一个的动机去改变一个类，那么这个类就具有多于一个的指责，应该把多余的职责分离出去，分别再创建一些类来完成每一个职责。单一职责原则是实现高内聚低耦合的最好办法。
       如果变化总是引起两个或多个职责同时发生变化，这时就应该将这些职责放到同一个类中。
       对于变化的封装，应该遵循以下原则：
       ①一个合理的类，应该仅有一个引起它变化的原因，即单一职责；
       ②在没有变化征兆的情况下应用SRP或者其他原则是不明智的；
       ③在需求实际发生变化时就应该应用SRP等原则来重构代码；
       ④利用测试驱动开发会迫使我们在设计出现问题前分离不合理的代码；
       ⑤如果测试不能迫使职责分离，僵化性和脆弱性的问题就会变得很突出，那就应该用外观（FaCade）或代理（Proxy）模式对代码重构。

3、里氏代换原则（LSP：Liskov Substitution Principle）：继承必须确保超类所拥有的性质在子类中依然成立，也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有继承的关系。LSP表述的是在同一个继承体系中的对象应该有共同的行为特征（状态&行为）。
       1988年，B.Meyer提出了契约式设计理论，从形式化方法中借鉴了一套确保对象行为和自身状态的方法，其基本概念很简单：
        ①每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执行。这称为前置条件；
        ②一旦通过前置条件的检验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件；
        ③对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式。
        以上为单个对象的约束条件。为了满足LSP，当存在继承关系时，子类中的方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松；而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格。

4、依赖倒置原则（DIP：Dependence Inversion Principle）： 如果一个类的一个成员或参数为一个具体类型，那么这个类就依赖于那个具体类型；如果在一个继承结构中，上层类中的一个成员或参数为一个下层类型，那么这个继承结构就是高层依赖于底层了，则需尽量面向接口或者抽象编程，即在高层和底层之间引入接口或者抽象类，让高层和底层同时依赖于抽象。
       抽象不应该依赖于细节，细节应该依赖于抽象。一些辅助原则可以帮助我们更好地运用依赖倒置原则：
       ①任何变量都不应该持有一个指向具体类的引用；
       ②任何类都不应该从具体类派生；
       ③任何方法都不应该覆盖它的任何基类中已经实现了的方法。 
       抽象反映高层策略，就是应用中那些不会随着具体细节的改变而改变的规则，常用的词语就是隐喻。仔细分析需求，先找出那些业务规则，然后把它们抽象出来形成接口。层次化的设计 ，常见的方法就是划分出显示层、业务层及持久层，再在每层做抽象。这是最粗糙的层次化，可以在每层再根据需要划分更细的层次。在实现的时候始终遵循前面提到的原则：只依赖于接口。

5、接口隔离原则（ISP：Interface Segregation Principle）：接口尽量细化，同时接口中的方法尽量少。一个接口中包含太多行为时，容易导致它们的客户程序之间产生不正常的依赖关系。
       接口隔离原则与单一职责的定义规则是不同的，单一职责要求的是类和接口职责单一，注重的是职责，没有要求接口的方法减少。接口隔离原则要求“尽量使用多个专门的接口”。专门的接口是指提供给多个模块的接口，拥有几个模块就应该提供几个接口，而不是建立一个庞大的臃肿的接口让所有的模块都可以来访问。
        接口要高内聚，就是提高接口、类、模块的处理能力，减少对外的交互，在接口中尽量少公布public方法，只提供访问者需要的方法。在实践应用时可以根据这样的规则来衡量：一个接口只服务于一个子模块或者业务逻辑。

6、迪米特法则（LoD：Law of Demeter）：每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。迪米特法则不希望类之间建立直接的接触，如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则可能造成系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系。
       为了克服狭义迪米特法则的缺点，可以使用依赖倒置原则。
       在将迪米特原则运用到系统的设计中时，需要注意以下几点：
       ① 在类的划分上，应当创建弱耦合的类，类之间的耦合越弱，就越有利于复用；
       ②在类的结构设计上，每一个类都应当尽量降低成员的访问权限；
       ③在类的设计上，只要可能，一个类应当设计成不变类；
       ④在对其他类的引用上，一个对象对其他对象的引用应降到最低；
       ⑤尽量限制局部变量的有效范围。 

7、其他原则
        ①重用发布等价原则（REP）：重用的粒度就是发布的粒度。
        ②共同重用原则（CCP）：一个包中的所有类应该是共同重用的，如果重用了包中的一个类，那么就要重用包中的所有类，相互之间没有紧密联系的类不应该在同一个包中。
        ③共同封闭原则（CRP）：包中所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响，则将对包中的所有类产生影响，而对其他包不造成任何影响。
        ④无依赖原则（ADP）：在包的依赖关系中不允许存在环，细节不应该被依赖。
        ⑤稳定依赖原则（SDP）：朝着稳定的方向进行依赖，应该把封装系统高层设计的软件放进稳定的包中，不稳定的包中应该只包含那些很可能会改变的软件。
        ⑥稳定抽象原则（SAP）：包的抽象成都应该和其他稳定程度一致。一个稳定的包应该是抽象的，一个不稳定的包也应该是抽象的。
        ⑦缺省抽象原则（DAP）：在接口和实现接口的类之间引入一个抽象类，这个类实现了接口的大部分操作。
        ⑧接口设计原则（IDP）：规划一个接口而不是实现一个接口。
        ⑨黑盒原则（BBP）：多用类的组合，少用类的继承。
        ⑩不要构造具体的超类原则（DCSP）：避免维护具体的超类。