OO设计原则

软件维护时间将要占软件生命周期的90%，说明软件的可扩展性是十分重要的

遵守设计原则将会极大提高软件的可维护性和可扩展性，使我们有时间专注于更重要的部分

每一个设计模式都体现了一个或多个设计原则：

 

一，单一职责原则（SRP，Single Responsibility Principle）

就一个类而言，应该仅有一个引起它变化的原因

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏

判断哪里将发生变化是很难的，特别要注意不要过度设计

找出应用中可能变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起（封装）

如何找到应用中可能变化的地方：

如果每次新的需求一来，都会使某部分的代码发生变化，那么就可以确定这部分代码需要被独立出来，和其他稳定代码有所区分

 

二，开放-关闭原则（OCP，Open Closed Principle）

类应该对扩展开放，对修改关闭（参考模式：Decorate Pattern）

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况

对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改

有时候，预先猜测什么地方会发生变化很难，同时，在所有地方都遵守“开放-关闭原则”是一种浪费（会引入新的抽象层次并增加代码复杂度）。因此，在我们最初编写代码时，可以先假设变化不会发生，以最快速、经济的方式实现功能。当变化发生时，我们可以立即创建抽象来隔离以后发生的同样变化。这样既不会过度设计，也能够为以后的扩展提供便利，算是设计与成本间的平衡点。当然，开发过程中就可以知道可能发生的变化是最好的，时间越长，建立抽象的成本越大，但凡事总是各有利弊

 

三，依赖倒置原则（DIP，Dependency Inversion Principle）

抽象不应该依赖细节，细节应该依赖抽象（参考模式：Factory Method Pattern）

高层模块不应该依赖底层模块，两个都应该依赖抽象

设计类时，从顶层模块开始，然后从上至下分析，创建顶层模块所需的底层模块，这种思考方式经常会导致顶层模块、底层模块之间的耦合

从底层模块开始，通过底层模块的共同特征抽象出抽象类，然后再回过头来设计顶层模块，由于已经抽象出抽象类，顶层模块无需针对具体的底层模块，依靠一个工厂获取特定的底层模块即可，这样就实现了顶层、底层模块之间的解耦

由下而上的设计、思考方式被称为倒置

针对接口编程，而不是针对实现编程，这里的接口不是单指interface，而是指超类型，超类型包含interface和abstract类

 

四， 里氏替换原则（ LSP，Liskov Substitution Principle）

子类型必须能够替换掉它们的父类型

只有当子类可以替换掉父类，软件功能不受影响时，父类才能真正被复用，而子类也能在父类的基础上增加新的行为

现实中的继承关系并不都能转化为程序设计中的继承关系，生物学上，企鹅是一种鸟类，但是程序设计中，由于企鹅不会飞，所以无法继承鸟类（企鹅并不能用来替换鸟类，因为其缺缺少鸟类必须的飞翔方法，违反里氏替换原则）

 

五，迪米特法则（LoD，Law of Demeter）

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类要调用另一个类的某一个方法的话，可以通过第三者转发这个调用

尽量降低类、成员以及方法的访问权限以降低直接调用的可能性

类之间的耦合度越低，越有利于复用

如果过多类耦合在一起，系统就会变得复杂易碎，修改系统中的一些类，会对系统中有关系的另一些类产生影响，需要消耗更多的精力维护

完全遵守迪米特法则将造成系统中存在大量中介类，增加系统复杂度，即便是法则，也要在合适的场景适度使用

参考门面模式，中介模式

 

六，多用组合，少用继承

继承在某些情况下会带来很多问题，极大降低程序的可扩展性，复用性，使程序难于维护（参考模式：Strategy Pattern）

 

原则与模式可以应用于软件开发周期的任何阶段（不仅仅在设计阶段，编码、重构时都会用到它们）