面向对象设计原则

一. 单一职责原则(SRP)

　　就一个类而言，只有一个引起它变化的原因。

　　如果一个类承载的职责过多，就等于把这些职责耦合在一起。一个职责的变化可能削弱或抑制这个类完成其他职责的能力。

　　这种耦合会导致脆弱的设计，当发生变化时，设计会遭受意想不到的破坏。

　　软件设计真正要做的就是，发现职责并把职责相互分离。

如果你能想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，应该进行分离。

例如：一场篮球比赛当中，既要判定队员是否犯规，还要进行计分。如果讲个两职责教给一个裁判的话，很容易造成比赛的混乱

二.开闭原则(OCP)

　　软件实体（类，模块，函数）应该是可扩展，不可修改的。

　　无论模块多少封闭，都会存在一些对之无法封闭的变化，既然不能完全封闭，设计人员就要对他设计的模块应该对哪些变化进行封闭做出选择。他必须猜测出最有可能发生变化的种类，然后构造抽象对这些变化进行隔离。

　　面对需求的变化，通过增加新代码来实现而不是改变现有的代码。

开发人员可以仅对程序中出现频繁变化的部分进行抽象，然而对于应用程序的每个部分都进行刻意的抽象同样不是一个好主意，拒绝不成熟的抽象与抽象一样重要。

例如：饭店要扩招一个配菜师，原来没有配菜师这个职位，只需要直接添加配菜师这个职位，不需要改动原本的员工体系。

 

三.依赖倒置原则(DIP)

　　高层模块不应该依赖于低层模块，两者都应该依赖于抽象。

抽象不应该依赖于细节，细节应该依赖于抽象。

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。

 

例如：

四.里氏替换原则(LSP)

子类必须能替换它的父类型。

任何基类可以出现的地方，子类一定可以出现。LSP是继承复用的基石，只有当子类可以替换基类，软件单位的功能不受影响时，基类才能真正的被复用，而子类也可以在基类的基础上增加新的行为。

五.接口分离原则(ISP)

　　采用多个与特定类有关的接口，比采用一个通用的涵盖多种业务的接口更好。

　　如果你拥有一个针对多个客户的类，为每一个客户创建特定业务接口，然后使该客户类继承多个特定业务接口将比直接加载客户所需所有方法有效。

六.迪米特原则(LoP)

　　迪米特原则又叫最少知识原则：如果两个类不直接发生通讯，那么这两个类就不应该发生直接的相互作用。

　　如果一个类要调用另一个类，则通过第三者调用。

　　迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

迪米特法则其根本思想强调的是类之间的松耦合。类之间的耦合越弱，越利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。

七.合成/聚合复用原则

合成/聚合复用原则：经常又叫做合成复用原则，就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新对象通过向这些对象的委派达到复用已有功能的目的。我白了就是要尽量使用合成/聚合，尽量不要使用继承。