软件设计六大原则

 单一职责原则（SRP：Single responsibility principle）：

     There should never be more than one reason for a class to change. 也就是说一个类只负责一件事。
好处：
          1.类的复杂性降低，一个类负责什么事，一目了然。
          2.类的可读性提高，复杂性降低，可读性当然提高。
          3.可维护性提高，可读性提高，能看懂了，也好维护了。
  4.变更引起的风险降低，变更是必不可少的，如果一个类设计的好， 变更引起的变化仅仅影响他的实现类，对其他的接口没有影响，这对系统的维护性和扩展性有很大提高。

坏处：
          过分的使用单一职责原则会增加大量的接口和类，提高了系统的复杂性。


使用场景： 单一职责原则适用于接口、类和方法。

建议：接口和方法一定要做到单一职责原则，类尽量做到一个原因引起变化。

对单一职责的最深理解就是，你只想安心的写会儿代码，但是不同的产品、测试不断的打断你，让你欲罢不能的痛苦。在生活工作中我们可能做不到，但是在软件设计里，它就是我们的乌托邦。

 里氏替换原则(Liskov Substitution Principle)

     Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.(所有引用基类的地方必须能够透明地使用其子类的对象)。
通俗地说，只要父类出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常。


如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生“畸变”，建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。


  里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。它包含以下4层含义：


1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。


2. 子类中可以增加自己特有的方法。


3. 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。


4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

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

     High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions  should noe depend upon details.Details should depend upon abstractions.

依赖倒置原则的本质就是通过抽象(接口或抽象类)使各个类或模块的实现彼此独立，不互相影响，实现模块间的松耦合。
面向接口编程就基本抓住了依赖倒置原则的核心。
危难时刻见真情，变更才显真功夫。如果你觉得你的代码完美，加个变化试一试！

- Clients should not be forced to depend upon interfaces that they don't use.(客户端不应该依赖它不需要的接口)
-   The dependency of one class to another one should depend on the smallest possible interface.(类间的依赖关系应该建立在最小的接口上)

接口隔离原则

接口隔离讲的就是尽量保持接口的纯洁性。和单一职责很像，但是他们强调的是两个方面。     单一职责要求专一是业务逻辑的划分，而接口隔离强调的是接口最好细化、提供最少的方法。

设计是有限度的，不能无限地考虑未来的变更情况，否则就会陷入设计的泥潭中而不能自拔。
     根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

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

迪米特法则又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。
Only talk to your immedate friends.(只与直接的朋友说话)

朋友圈的确定

“朋友”条件：
1）当前对象本身（this）
2）以参量形式传入到当前对象方法中的对象
3）当前对象的实例变量直接引用的对象
4）当前对象的实例变量如果是一个聚集，那么聚集中的元素也都是朋友
5）当前对象所创建的对象

任何一个对象，如果满足上面的条件之一，就是当前对象的“朋友”；否则就是“陌生人”。

狭义的迪米特法则的缺点：
在系统里造出大量的小方法，这些方法仅仅是传递间接的调用，与系统的商务逻辑无关。

遵循类之间的迪米特法则会是一个系统的局部设计简化，因为每一个局部都不会和远距离的对象有直接的关联。但是，这也会造成系统的不同模块之间的通信效率降低，也会使系统的不同模块之间不容易协调。

门面模式和调停者模式实际上就是迪米特法则的应用。

开闭原则

Software entities like classes, modules and functions should be open for extension but closed for modifications.(一个软件实体如类、模块和函数应该对扩展开放，对修改关闭)。也就是说一个软件应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。

变化：

     1.逻辑变化

     2.子模块变化

     3.可视视图变化