转载

跟Bob大叔观OO原则

上篇总结了经典的23种设计模式，详细的解读后期会陆续的详细揭开。使用设计模式的根本原因就是为了增强代码的复用性和可维护性。而面向对象是实现代码复用的有效途径，所以这里有必要了解一下OO的基本思想和原则。

面向对象设计的原则（OOD&OOP）主要分为两大类，一类是面向类的，另一类是面向包的。设计模式基本都是围绕面向类的几个原则的实践，而面向包的几个原则主要体现在架构模式中。

S.O.L.I.D

Bob大叔（Robert C. Martin）的大名如雷贯耳，相信大部分在进击中的开发者都有阅读过经典著作《敏捷软件开发》的经历，受益匪浅。

在面向对象的程序的设计和开发过程中时，有5个原则非常重要，此外还有一个法则我们应该尽量去遵守它。

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

2、开放封闭原则（OCP，The Open Closed Principle）

3、里氏替换原则（LSP，The Liskov Substitution Principle）

4、依赖倒置原则（DIP，The Dependency Inversion Principle）

5、接口分离原则（ISP，The Interface Segregation Principle）

6、迪米特法则（LoD，The Law of Demeter、LKP）

SRP

A class should have only one reason to change.一个类应该仅有一个引起它变化的原因。

SRP是所有原则中最简单的一个，概念简洁易懂。但却也是最难正确运用，或者说是最容易过度使用的原则。

一方面，因为SRP把职责定义成了变化的原因，如果我们能够找到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。比如开发者经常会习惯性的把职责归类式的结合在一起，而正确的做法是发现职责并把这些职责相互分离。

另一方面，如果程序的变化方式总是导致N个职责（N>1）同时变化，那么就没必要分离它们了。在这里有一个推论：仅当变化发生时，变化的轴线才具有实际的意义。在实际的设计和开发过程中，一定要把握好分离“单个”职责的度，所谓过犹不及，过度的分离只能适得其反，违背了面向对象的封装思想。

OCP

Software entities(classes,modules,functions,etc.) should be open for extension, but closed for modification.软件实体（如类、模块、函数等）应该对扩展开放，对修改关闭。

OCP是整个面向对象设计的核心。它代表了灵活性、可重用性和可维护性。

乍一看，两个特征似乎有所矛盾，扩展模块的功能通常是以修改模块的源代码作为手段。但是，我们有“抽象”！通过创建稳定的但又能描述一组任意个可能行为的抽象基类，并将具体的行为实现为派生类，这种做法能很好的解决开放扩展的问题。主要是针对软件中频繁变化的那部分作出合理的抽象。

当然，创建和使用抽象会增加软件复杂性和团队的精力，所以肆意的进行抽象显然并不是一个好设计，简直是折磨人。除非你有强大的智商优越感，但是面对广大平凡质朴的程序员，还请手下留情。

拒绝不成熟的抽象和抽象本身一样重要。

LSP

Derived types must be completely substitutable for their base types.子类型必须能够完全的替换掉它们的基类型。

LSP是使OCP成为可能的主要原则之一，也是继承层次特征的主要设计原则。

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件中，把父类都替换成它的子类，程序行为没有或者不发生变化。也就是说，只有当子类可以替换掉父类，软件的功能不受到影响时，父类才能真正的被复用，而子类也能够真正的在父类的基础上增加新的行为。

子类型的可替换性使得使用基类型表示的模块在无需修改的情况下就可以扩展。可替换性可以通过显示或者隐式的契约来定义。

DIP

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

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

B. Abstractions should not depend on details. Details should depend on abstractions.

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

DIP是面向对象设计的标志。

依赖倒置原则是实现许多面向对象技术所宣称的好处的基本低层机制，他的正确应用对于创建可重用的框架来说是必须的。同时它对于构建在变化面前富有弹性的代码也是非常重要的，由于抽象和细节彼此隔离，所以代码也非常容易维护。

针对接口编程，而不要对实现编程。倒置接口的所有权。

LSP和DIP乍一看还有点相似，其实，他们还是有区别的：

两个原则所站的角度不同。LSP是站在模式对象的角度，而DIP则是站在客户端程序的角度；模式对象一方将“相对多变的”子类视同它的接口（或父类），而客户程序依赖的内容是“相对稳定”的接口。

ISP