面向对象设计原则，详细介绍及分析

一、介绍：

        面向对象设计原则是面向对象设计的基石，是面向对象设计的质量、保障、思想。

        一共有七个设计原则，设计模式就是面向对象设计原则的经典应用

单一职责原则* 强调：高内聚低耦合，每一种类型的业务区分

开闭原则* 强调：面向接口编程，对扩展开放，对修改关闭；提高复用性、维护性

里氏替换原则 强调：是符合开闭的重要保证

依赖倒置原则* 强调：多态，面向接口编程

接口分离原则 强调：细化接口，提高代码可维护性、灵活性；

迪米特原则 强调：

组合/聚合复用原则 强调：

二、原则分析

1. 单一职责原则

概念：

        单一职责原则 SRP --- Single Responsibility Principle

        There should never be more than one reason for a class to change。

        应该有且仅有一个原因引起类的变更。

        系统中的每个类都应只有一个职责，而所有类所关注的就是自身职责的完成。

                1. 职责是指为“变化的原因”。

                2. 如果能想到多个原因去改变一个类，这个类就具有多个职责。

                3. 并不是单一功能原则，并不是每个类只能有一个方法，而是单一“变化的原因”原则。

                4. 如果一个类有多个职责，这些职责就耦合在了一起，当一个职责发生变化时，可能会影响其它的职责。

                5. 多个职责耦合在一起，会影响复用性（可能只需要复用该类某一个职责，但该职责跟其它职责耦合在一起，很难分离出来）。

好处：

        单一职责原则的意思就是经常说的“高内聚、低耦合”。

举例：

        饭店中的不同员工具有 不同的职责，我们不需要老板一肩扛起所有工作，可以安排不同岗位的员工。即使某个员工离职了，也比较好招聘到新员工

注意：

        1. 单一职责原则是所有原则中最简单的、最难应用的一个；要注意过犹不及

        2. “变化的原因”，只有实际发生时才有意义。可能预测到会有多个原因引起这个类的变化，但这仅仅是预测，并没有真的发生，这个类仍可看做具有单一职责，不需要分离

2. 开闭原则OCP

概念：

        开闭原则OCP--Open Closed Principle

        Software entities should be open for extension,but closed for modification。

        软件实体应当对扩展开放，对修改关闭。更通俗翻译：软件系统中的各种组件，如模块（Modules）、类（Classes）以及功能（Functions）等，应该在不修改现有代码的基础上，引入新功能。

        1. 实现开闭原则的关键是抽象。

        2. 定义一个抽象层，只规定规范而不提供实现，实现通过定义具体类来完成。

        3. 需求变化时不是通过修改抽象层来完成，而是通过定义抽象层新实现完成。

        4. 通过抽象类及接口，规定了具体类的特征作为抽象层，相对稳定，不需修改，从而满足“对修改关闭”；从抽象类导出的具体类可以改变系统的行为，从而满足“对扩展开放”。

好处：

        1. 通过扩展已有软件系统，可提供新的行为，以满足对软件的新需求，提高了软件系统的适应性和灵活性。

        2. 已有的软件模块，特别是最重要的抽象层模块不能再修改，提高了软件系统的一定的稳定性和延续性。

        3. 这样的设计同时也满足了可复用性与可维护性。

举例：

        定义飞行接口Flyable，可以有多个实现类。showFly()使用Flyable作为参数，可以传递所有实现类的对象。有了新选手，增加实现类即可。不需要修改showFly()所在的类。

注意：

        1. 实现开闭原则的关键是抽象。

        2. 抽象层相对稳定不需修改，需求变化后通过重新定义抽象层的新实现来完成。

        3. 即使无法百分之百的做到开闭原则，但朝这个方向努力，可以显著改善一个系统的结构。

        4. 对系统每个部分都肆意地进行抽象也不是一个好主意，应该仅仅对程序中需求频繁变化部分进行抽象。拒绝不成熟的抽象和抽象本身一样重要。

        5. 开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。其他设计原则都可以看作是开闭原则的实现手段或方法。

3. 里氏代替原则LSP

概念：

        里氏替代原则LSP--Liskov Substitution Principle ​

        所有引用基类的地方必须能透明地使用其子类的对象。

        通俗点讲只要父类能出现的地方子类就可以出现，而且调用子类还不产生任何的错误或异常，调用者可能根本就不需要知道是父类还是子类。但是反过来就不成了，有子类出现的地方，父类未必就能适应。

里氏替换法则包含了四层意思：

1. 子类必须完全实现父类的方法--重写。

2. 子类可以有自己的个性----子类中可以定义特有的方法。

3. 覆盖和实现父类的方法时，输出结果（返回值）可以被缩小，但不能被放大。

好处：

        里氏代换原则对如何良好继承提出了衡量依据

举例：

        1. 企鹅/鸵鸟是鸟吗？

        2. 玩具手枪是手枪吗？

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

总结：

        采用开闭原则必然用到抽象和多态，而这离不开继承。而里氏代换原则对如何良好继承提出了衡量依据。里氏代换原则是使代码符合开闭原则的一个重要保证。

4. 依赖倒置原则DIP(接口)

概念：

        依赖倒置原则DIP --Dependence Inversion Principle

        High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions。翻译过来，包含三层含义：高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

        抽象：即抽象类或接口，两者是不能够实例化的。

        细节：即具体的实现类，实现接口或者继承抽象类的类，可通过关键字new直接被实例化。

        依赖正置就是类间的依赖是实实在在的实现类间的依赖，也就是面向实现编程。

        依赖倒置原则的本质其实就是通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合, 面向要求进行依赖。

好处：

        采用依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，减少并行开发引起的风险，提高代码的可读性和可维护性。

举例：

        早期电脑所有硬件整合在一起，一个模块坏全部坏，现在的电脑依赖于插槽（规范），更换cpu、内存、卡等方便。

司机驾校培训出来不是只会开宝马、或者只会开奔驰，而是可以开所有汽车。

总结：

        接口编程，理解了面向接口编程，也就理解了依赖倒置

        如果没有实现依赖倒置原则，那么也就意味着开闭原则也无法实现。

        结合实际情况使用此原则，要考虑生产和成本，不能生搬硬套

5. 接口分离原则ISP

概念：

        接口分离原则ISP-- Interface Segregation Principle

        有两种定义：

                第一种：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.类间的依赖关系应该建立在最小的接口上。

        接口隔离原则的含义：

               建立单一接口，不要建立庞大臃肿的接口，尽量细化接口，接口中的方法尽量少。也就是说，要为各个类建立专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

好处：

        防止庞大、臃肿的接口，避免“接口污染”，提高灵活性和可维护性

举例：

        在车站售票窗口排队的人有买票的，有查开车信息，有退票的，不必排在同一窗口中。多开几窗口，每个窗不同功能，让不同需求的人排在不同窗口，可以节约时间和人力。

总结：

        ​ 1. 注意控制接口的粒度，接口不能太小，如果太小会导致系统中接口泛滥，不利于维护；

        ​ 2. 接口也不能太大，太大的接口将违背接口隔离原则，灵活性较差，使用起来很不方便。

        ​ 3. 一般而言，接口中仅包含为某一类用户定制的方法即可，不应该强迫客户依赖于那些它们不用的方法。

6. 迪米特法则LOD

概念：

        迪米特法则LOD-- Law of Demeter

        talk only to your immediate friends

        只与你直接的朋友通信（不跟陌生人说话，朋友越少越好）

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

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

好处：

        尽量降低类与类之间的耦合

举例：

        买房找一个中介即可，不用是认识很多卖房人。去医院看病不用自己知道所有科室的位置，找一个导医即可。

总结：

        1. 过分使用迪米特原则会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。

        2. 外观模式和中介者模式都是迪米特法则的应用

7. 组合/聚合复用原则

概念：

        合成/聚合复用原则CARP-- Composite Aggregate Reuse Principle

        Favor object composition over class inheritance.

        优先使用对象组合，而不是类继承。

        合成聚合复用原则是指在一个新对象中通过关联关系（组合和聚合关系）使用原来已经存在的一些对象，看做为新对象的一部分，新的对象通过向这些原来已经具有的对象委派相应的动作或者命令达到复用已有功能的目的。

为何“要尽量使用合成和聚合，尽量不要使用继承”呢？这是因为：

        第一， 继承复用破坏包装，它把超类的实现细节直接暴露给子类，这违背了信息隐藏的原则。

        第二， 如果超类发生了改变，那么子类也要发生相应的改变，这就直接导致了类与类之间的高耦合，不利于类的扩展、复用、维护等，也带来了系统僵硬和脆弱的设计。

        第三， 从超类继承而来的实现是静态的，不可能再运行时间内发生改变，因此没有足够的灵活性。

        而是用合成和聚合的时候新对象和已有对象的交互往往是通过接口或者抽象类进行的，就可以很好的避免上面的不足，而且这也可以让每一个新的类专注于实现自己的任务，符合单一职责原则。

好处：

        非常有利于构建可维护、可复用、可扩展和灵活性好的软件系统。

举例：

总结：

        1. 组合与继承都是重要的复用方法。组合称为黑箱复用，继承称为白箱复用。

        2. 在开发的早期，继承被过度地使用；随着时间发展，人们发现优先使用组合可以获得复用性与简单性更佳的设计

        3. 并非不要使用继承，并非继承一无是处，而是不要滥用继承。合成/聚合也有自己的缺点