面向对象编程solid原则

• 单一职责(Single Responsibility)：类和对象最好是只有单一的职责，在程序设计中如果发现某些类存在多个职责，可以考虑进行拆分；
• 开闭原则(Open-close, open for extension, close for modification)：设计要对扩展开放，对修改关闭，换句话说，程序应保证平滑的扩展性，尽量避免因为新增同类功能而修改现有设计，这样可以少产出些回归问题；
• 里式替换(Liskov Substitution)：这是面向对象的基本要素之一，凡是可以使用父类或者基类的地方，都可以用子类替换；
• 接口分离(Interface Segregation)：在我们进行接口的设计时，如果一个接口定义了太多方法，那么在某个类实现这个接口时，可能面临两难，某些方法是不用的，这就破坏了程序的内聚性；
  对于这种情况，可以将功能单一的接口进行拆分，这样，在添加新功能时可以在不改变原有接口的基础上进行功能的扩展；
• 依赖反转(Dependency Inversion)：实体应该依赖于抽象而不是实现，也就是说高层次的模块，不应该依赖于低层次模块，而是应该基于抽象，实践这一原则是保证代码适当耦合度的法宝。

一、单一职责原则（SRP）

从面向对象角度解释这个原则为："引起类变化的因素永远不要多于一个。" 或者说 "一个类有且仅有一个职责"。这似乎不太好理解，特别是"引起类变化的因素永远不要多于一个。"这句话更是有点虚，让人有点摸不着头脑。

我们通常都说“低耦合，高内聚”。在我看来，这里的"单一职责"就是我们通常所说的“高内聚”，即一个类只完成它应该完成的职责，不能推诿责任，也不可越殂代疱，不能成为无所不能的上帝类。如果你的团队中实施宽松的“代码集体所有权”，在编码的过程中出现许多人同时修改（维护）同一个类的现象，而且成员之间的沟通不够及时，主动和畅通的话，那么时间一长，就很可能出现“承担过多职责”的上帝类。这时，提炼基类/接口和提炼类重构将能帮助我们消除或减轻这种设计臭味。

看一个例子：

这是一个违反了“单一职责原则” 的类结构图。

这里，Rectangle类做了下面两件事：

计算矩形面积；

在界面（绘制设备）上绘制矩形；

并且，有两个应用使用了Rectangle类：

计算几何应用程序（Computational Geometry Application）用这个类计算面积；

图形程序（Graphical Application）用这个类在界面上绘制矩形；

这违反了SRP(单一职责原则)。因为Rectangle类做了两件事，在一个方法里它计算了面积，在另外一个方法了它返回一个表示矩形的GUI。这会带来一些有趣的问题：在计算几何应用程序中我们必须包含GUI。也就是在开发几何应用时，我们必须引用GUI库；图形应用程序中Rectangle类的变化可能导致计算几何应用程序的变化，编译和测试，反之亦然。那么，怎么修改才能让其符合单一职责原则呢？

答案是：拆分！拆分职责到两个不同的类中，如：

Rectangle: 这个类应该只定义Area()方法；

RectangleUI: 这个类应继承Rectangle类，并定义Draw()方法。

二、开放封闭原则 （OCP）

从面向对象设计角度看，这个原则可以这么理解："软件实体(类,模块,函数等等)应当对扩展开放，对修改闭合。" 通俗来讲，它意味着你（或者类的客户）应当能在不修改一个类的前提下扩展这个类的行为。在OOD里，对扩展开放意味着类或模块的行为能够改变，在需求变化时我们能以新的，不同的方式让模块改变，或者在新的应用中满足需求。

也就是说，对扩展是开放的，而对修改是封闭的。我们通常都说：向系统中增加功能时应该只是添加新代码，而应该尽量少的修改原代码。在我看来，这就是遵循开放封闭原则所能带来的效果。曾经在网上看到过这样一句话“哪里变化，封装哪里”。这其实就是说，我们要将系统中可能变化的地方封装起来，即对修改封闭。同时，为了应对系统需求（功能）的扩展，需要抽象！

这里抽象是关键。《设计模式》中的state模式和strategy模式是这个原则的最好体现。

举一个例子：

违反了开放封闭原则的类结构图。

客户端代码直接面向服务器端的具体实现编程，缺乏灵活性。这样如果服务器因为某些原因被其他服务器替换了，那么客户端调用服务器的代码也必须做相应的修改或替换。这其实就是”面向实现编程“的设计臭味！

那么，如何修改才能得到正确灵活的设计？

答案是：抽象！为服务器端的代码（类型）抽象出一个抽象基类（定义一组完成服务职责的最小接口）。

下面是正确的设计：

遵循开放封闭原则的类结构图。

基本上，你抽象的东西是你系统的核心内容，如果你抽象得好，很可能增加一个新的服务器类型（扩展）只需要添加新类型（继承自AbstractServer即可）。因此代码要尽可能以抽象(这里的AbstractServer)为依据，这会允许你扩展抽象事物，定义一个新的实现而不需要修改任何客户端代码。即”面向接口编程，不要面向实现编程“！

三、Liskov's 替换原则（LSP）

Liskov's 替换原则意思是："子类型必须能够替换它们的基类型。"或者换个说法："使用基类引用的地方必须能使用继承类的对象而不必知道它。" 这个原则正是保证继承能够被正确使用的前提。通常我们都说，“优先使用组合（委托）而不是继承”或者说“只有在确定是 is-a 的关系时才能使用继承”，因为继承经常导致”紧耦合“的设计。

在基本的面向对象原则里，"继承"通常是"is a"的关系。如果"Developer" 是一个"SoftwareProfessional",那么"Developer"类应当继承"SoftwareProfessional"类。在类设计中"Is a"关系非常重要，但它容易冲昏头脑，导致使用错误的继承造成错误设计。

看一个最最经典的例子：

遵循Liskov替换原则的类结构图。

注：这里，KingFisher（翠鸟）类扩展了Bird基类，并继承了Fly()方法，这没有问题。

但是下面这个类结构图就存在设计上的问题：

违反Liskov替换原则的类结构图。

Ostrich(鸵鸟)是一种鸟，这毋庸置疑，并从Bird类继承，这从概念上说没有问题。但是鸵鸟它能飞吗？不能，那么这个设计就违反了LSP。因为在使用Bird的地方不一定能用Ostrich代替。所以，即使在现实中看起来没问题，在类设计中，Ostrich不应该从Bird类继承，这里应该从Bird中分离一个不会飞的类NoFlyBrid，Ostrich应该继承这个不会飞的鸟类NoFlyBrid。

为什么LSP如此重要？

如果没有LSP，类继承就会混乱；如果子类作为一个参数传递给方法，将会出现未知行为；

如果没有LSP，适用与基类的单元测试将不能成功用于测试子类；

四、接口分离原则（ISP）

这个原则的意思是"客户端不应该*依赖于它们不用的接口。" 也就是说，一个接口或者类应该拥有尽可能少的行为（那么，什么叫尽可能少？就是少到恰好能完成它自身的职责），这也是保证“软件系统模块的粒度尽可能少，以达到高度可重用的目的。

接口包含太多的方法会降低其可用性，像这种包含了无用方法的"胖接口"会增加类之间的耦合。如果一个类想实现该接口,那么它需要实现所有的方法,尽管有些对它来说可能完全没用，所以这样做会在系统中引入不必要的复杂度，降低代码的可维护性或鲁棒性。

接口分离原则确保实现的接口有它们共同的职责,它们是明确的,易理解的,可复用的.

下面这个例子充分的说明了”接口应该仅包含必要的方法，而不该包含其它的“。如果一个接口包含了过多的方法，应该通过分离接口将其拆分。

这是一个违反接口分离原则的胖接口。

注意到IBird接口包含很多鸟类的行为,包括Fly()行为.现在如果一个Bird类(如Ostrich)实现了这个接口，那么它需要实现不必要的Fly()行为(Ostrich不会飞)。因此，这个"胖接口"应该拆分成两个不同的接口，IBird和IFlyingBird, 而IFlyingBird继承自IBird。如下图所示：

这样的话，重用将变得非常灵活：如果一种鸟不会飞(如Ostrich)，那它实现IBird接口。如果一种鸟会飞(如KingFisher)，那么它实现IFlyingBird。

因此，如果我们想要获得可重用的方案，就应当遵循接口分离原则，把接口定义成仅包含必要的部分，以便在任何需要该接口功能的地方复用这个接口。

五、依赖倒置原则（DIP）

这个原则的意思是：高层模块不应该依赖底层模块，两者都应该依赖其抽象。其实又是”面向接口编程，不要面向实现编程“的内在要求。

我们考虑一个现实中的例子，来看看依赖倒置原则给我们软件带来的好处。 

你的汽车是由很多如引擎，车轮，空调和其它等部件组成，对吗？

注意：这里的 Car 就是高层模块；它依赖于抽象接口IToyotaEngine 和 IEighteenInchWheel.

而具体的引擎FifteenHundredCCEngine 属于底层模块，也依赖于抽象接口IToyotaEngine ；

具体的车轮 EighteenInchWheelWithAlloy同样属于底层模块，也依赖于抽象接口IEighteenInchWheel。

上面Car类有两个属性（引擎和车轮列表），它们都是抽象类型(接口)。引擎和车轮是可插拔的，因为汽车能接受任何实现了声明接口的对象，并且Car类不需要做任何改动。

除SOLID原则外还有很多其它的面向对象原则。如：

"组合替代继承":这是说相对于继承，要更倾向于使用组合；

"笛米特法则"：这是说"你的类对其它类知道的越少越好"；

"共同封闭原则"：这是说"相关类应该打包在一起"；

"稳定抽象原则"：这是说"类越稳定，越应该由抽象类组成";

当然，这些原则并不是孤立存在的，而是紧密联系的，遵循一个原则的同时也就遵循了另外一个或多个原则；反之，违反了其中一个原则也很可能同时就违反了另外一个或多个原则。 设计模式是这些原则在一些特定场景的应用结果。因此，可以把设计模式看作"框架"，把OOD原则看作"规范"。 在学习设计模式的过程中，我们要经常性的反思，这个设计模式体现了面向对象设计原则中的哪个或哪一些原则。

特别是在重构实现模式，或重构趋向模式的过程中，我们更要结合SOLID原则思考代码在重构前后的区别，理解它的改进。我正在研读《重构与模式》一书，因此接下来我会结合例子记录自己的学习体会。

注：以上图片均来自《如何向妻子解释OOD》译文链接：http://www.cnblogs.com/niyw/archive/2011/01/25/1940603.html

<How I explained OOD to my wife> 原文链接：http://www.codeproject.com/Articles/93369/How-I-explained-OOD-to-my-wife

还有两个常被提到的原则：

六、合成复用原则（CRP）

合成复用原则（Composite Reuse Principle,CRP），即优先使用委托而不是继承来重用已用功能（代码）。循序这一原则通常也是避免触犯里氏替换原则所要求的。

七、迪米特法则（LoD / LKP）

迪米特法则（Law Of  Demeter）又称最小知识原则（Least Knowledge Principle, LKP）。意思是一个对象应当对其它对象有尽量好的了解，即应该保持对象间有尽量少的相互作用是，使得对象（类）具有好的独立性，可测试性，也就易于维护。

关于“迪米特法则”的其它表述还有：只与你的朋友们通信，不要与“陌生人”说话。设计模式中的Facade模式和Mediator模式就是使用了这一原则，降低模块间的耦合