我是怎样教媳妇面向对象编程的 (转载)

妻子：我也正想问呢。

丈夫：如果代码符合以下几点，那么你就在“面向对象设计”：

• 面向对象
• 复用
• 变化的代价极小
• 无需改代码即可扩展

妻子：然后呢？

丈夫：不只我们。很多人也花了很多时间和精力思考这个问题上，他们尝试更好的进行“面向对象设计”，并为“面向对象设计”指出几条基本的原则(你可以用在你的“面向对象设计”中)。他们也确实总结出了一些通用的设计模式(基于基本的原则)。

从面向对象角度解释是：

"导致类变化的因素永远不要多于一个。"

或者换行个说法："一个类有且只有一个职责"。

妻子：可以解释一下么？

丈夫：当然，这个原则是说，如果有多于一个原因会导致你的类改变(或者它的职责多余一个)，你就需要根据其职责把这个类拆分为多个类。

妻子：嗯...这是不是意味着在一个类里不能有多个方法？

丈夫：当然不是。你当然可以在一个类中包含多个方法。问题是，他们都是为了一个目的。那么，为什么拆分很重要的？

那是因为：

• 每个职责都是轴向变化;
• 如果类包含多个职责，代码会变得耦合;

妻子：给个例子呗？

丈夫：木有问题啊，瞅瞅下面类的结构。其实，这个例子是 Bob 叔叔那儿来的，得谢谢他。

违反SRP原则的类层次结构

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

• 计算矩形面积;
• 在界面上绘制矩形;

而且，有两个程序使用了 Rectangle 类：

• 计算几何应用程序用这个类计算面积;
• 图形程序用这个类在界面上绘制矩形;

这违反了SRP原则(单一职责原则)!

妻子：肿么回事？

丈夫：你瞅瞅，Rectangle 类干了俩不相干的事。一个方法它计算了面积，另外一个它返回一个表示矩形的 GUI 资源。这问题就有点乐了：

• 在计算几何应用程序里咱得包着 GUI。就是说，写几何应用代码，咱也得引用 GUI 库;
• 要是为了图形应用所改变 Rectangle 类，计算几何应用也可能跟着变，然后还得编译，还得测试，另一边也是;

妻子：是很乐。就是说，咱得根据类的职责分开写呗？

丈夫：必须滴。猜猜怎么干？

妻子：我想想，我寻思这得这么办：

我瞅着得按职责拆成两个类：

• Rectangle：这个类定义 Area() 方法;
• RectangleUI：这个把 Rectangle 类继承过来，定义 Draw() 方法。

丈夫：很好。这么个，计算几何应用使 Rectangle 类，图形应用使 RectangleUI 类。咱还可以把这俩类分到俩单独的 DLL 中，然后改的时候就不用管另一个了。

妻子：谢了，我大概明白 SRP 原则了一句话：SPR 就是把东西分到不能再分了，再集中化管理和复用。囔，在方法层面上，咱不也得用 SPR 原则？我是说，咱写的方法里有很多干不同事儿的代码，这也不符合 SPR原则吧。

丈夫：你说地不差。方法也得分开，一个方法干一个活。这么着你复用方法，要是改了，也不用改太多。

话题：开闭原则

作者：“开闭原则“图示如下：

图：开闭原则图

让我来解释一下，设计规则如下：

“软件实体（类，模块，函数等）应该对扩展开放，对修改关闭。”

这意味着在最基本的层面上，你可以扩展一个类的行为，而无需修改。这就像我能够穿上衣服，而对我的身体不做任何改变，哈哈。

妻子: 太有意思啦. 你可以通过穿不同的衣服来改变你的外貌, 但是你不必为此改变自己的身体.所以你是对扩展开放的, 对吧?

丈夫: 是的. 在面向对象设计中, 对扩展开放意味着模块/类的行为可以被扩展,那么当需求变化时我们可以用各种各样的方法制定功能来满足需求变更或者新需求

妻子: 除此之外你的身体是对修改关闭的. 我喜欢这个例子. 所以, 对于核心模块或类的代码在需要扩展的时候不应该被修改. 你能结合具体例子解释下吗?

丈夫: 当然了, 先看下面的例子.这个就不支持 "开放-关闭" 原则:

类的层次结构已经表明了这是违反"开放-关闭"原则的.

你看, 客户端类和服务端类都是具体的实现类. 因为, 如果某些原因导致服务端实现改变了, 客户端也需要相应变化.

妻子: 有道理. 如果一个浏览器的实现和一个指定的服务器(比如IIS)紧紧的耦合在一起 , 那么如果服务器由于某种原因替换成了另外的 (比如, Apache) 浏览器也需要做相应的变化或者被替换掉. 多么恐怖的一件事啊!

丈夫: 非常正确. 因为下面的将是一种好的设计方案:

类的层次关系展示了"开放-关闭"原则

在这个例子中, 添加了一个抽象的Server类, 并且客户端保持了抽象类的引用, 具体的Server类实现了这个抽象Server类. 所以, 由于某种原因Server的实现类发生了改变, 客户端不需要做任何改变.

这里的抽象的Server类对修改关闭, 具体的Server实现类对扩展开放.

妻子: 我的理解是, 抽象是关键, 对吗?

丈夫: 是的, 基本上, 你要对系统的核心业务进行抽象, 如果你抽象化做的比较好, 很可能, 在扩展功能的时候它们不必做任何改变 (比如Server就是一个抽象的概念).  你所定义的抽象的实现 (比如, IIS服务器 实现了 Server) 和 抽象的代码 (Server) 要尽可能的多. 这样在客户端代码中不需要做任何修改就会允许你定义一个新的实现(比如, ApacheServer) .

主题: 里氏替换原则

丈夫: "里氏替换原则"听起来非常的复杂,但是设计思想却是非常基础的. 看下面这个有趣的海报

里氏替换原则海报

原则描述了:

"子类型必须能够替换它们的基类."

或者, 换句话说:

"使用基类引用的函数必须能够使用派生类而无须了解派生类."

丈夫：是的，亲爱的，确实如此。让我们来看看一个例子：

类层次结构图展示的是一个Liskov替换原则的例子.因为 KingFisher类拓展(继承)了Bird类，因此继承了Fly()这个方法,这是非常不错的.

我们再来看看下面的例子

修正过的Liskov替换原则的类层次结构图

Ostrich（鸵鸟）是一种鸟（显然是），并继承了 Bird 类。但它能飞吗？不能，这个设计就违反了里氏替换原则。

因此，即使在现实中看上去没什么问题，在类设计中，Ostrich 都不应该继承 Bird 类，而应该从 Bird 中分出一个不会飞的类，由 Ostrich 继承。

妻子：好吧，明白了。我说说为什么里氏替换原则如此重要：

• 如果不遵循 LSP原则，类继承就会混乱。如果子类实例被作为参数传递给方法，后果难以预测。
• 如果不遵循 LSP原则，基于父类编写的单元测试代码将无法成功运行子类。

我说的对吗？

作者：完全正确，你可以设计一个对象并用LSP作为验证工具来测试该对象是否能够继承。

话题：接口隔离原则

作者：今天我们讲下“接口隔离原则”，看看下面这张海报

接口隔离原则海报

妻子：这是什么意思？

作者：它的意思是这样的：“用户不应该被迫依赖他们不使用的接口。”

妻子：解释一下。

作者：好吧，解释如下：

假设你想去买一台电视机并且有两种类型可以选择，其中一种有很多开关和按钮，但是多数对你来说用不到，另一种只有几个开关和按钮，并且看来你很熟悉怎么用。如果这两种电视机提供同样的功能，你会选择哪一种？

妻子：当然是第二种了。

作者：嗯，但是为什么呢？

妻子：因为我不需要看起来很麻烦而且对我也不必要的开关和按钮。

丈夫：正确。同样的，假如你有一些类，你通过接口暴露了类的功能，这样外部就能够知道类中可用的功能，客户端也可以根据接口来设计。当然那，如果接口太大，或是暴露的方法太多，从外部看也会很混乱。接口包含的方法太多也会降低可复用性， 这种包含无用方法的”胖接口“无疑会增加类的耦合。

这还会引起其他的问题。如果一个类视图实现接口，它需要实现接口中所有的方法，哪怕一点都用不到。所以，这样会增加系统复杂度，降低系统可维护性和稳定性。

接口隔离原则确保接口实现自己的职责，且清晰明确，易于理解，具有可复用性。

妻子：我明白了，你的意思是接口只应该包括必要的方法而不是所有的。

作者：是的，让我们看一个例子。

下面的接口是一个“胖接口”，这违反接口隔离原则：

违反接口隔离原则的接口示例

注意，IBird接口定义 Fly（）的行为有许多鸟类的行为。现在，如果一只鸟类（比方说，鸵鸟）实现了这个接口，它将会实现不必要的 Fly（）的行为（鸵鸟不会飞）。

妻子：是啊。因此，这个接口必须被分割？

作者：是的，“胖接口”应该分隔成两个不同的接口，IBird 和IFlyingBird，而IFlyingBird继承于IBird。

接口隔离原则的例子中正确版本的接口

如果有一只不会飞的鸟（比如，驼鸟），只要用IBird接口即可，如果有一保会飞的鸟（比如，翠鸟），只要用IFlyingBird接口即可。

妻子：所以，回过头来看有很多按钮开关的电视的例子，制造商应该有电视机的图纸，开关和按钮也在这个方案里。若他们想造一台新款电视机时想要复用这张图纸，他们必须添加更多的按钮和开关，否则没法复用，对么？

丈夫：对。

妻子：若是他们真的想要复用这个方案，他们应该将电视机的图纸分为更小的部分，才能在以后制造新款电视机的时候复用这些设计方案。

丈夫：你理解了。

话题：依赖倒置原则

作者：这是SOLID原则中最后的原则。图示如下：

依赖倒置原则图示

它的意思是：

“高层次的模块不应该依赖于低层次的模块，而是，都应该依赖于抽象。”

作者：我们用一个现实的例子来理解。你的汽车是用很多部件组成，比如发动机，车轮，空调和其他的部件，是吧？

妻子：是啊，当然是这样。

妻子：那太可怕了！这样的话，要是汽车引擎故障，你得整车修理，或者买一辆新车！

丈夫：是的，那么怎么做到"可插拔"呢？

妻子：关键是”抽象“，是吧？

丈夫：对。现实世界中，汽车是高层级的模块/实体，它依赖于底层级的模块/实体，例如引擎和轮子。

相较于直接依赖于实体的引擎或轮子，汽车应该依赖于抽象的引擎或轮子的规格，这样只要是符合这个抽象规格的引擎或轮子，都可以装到车里跑。

来看看下面的图：

依赖倒置原则的类层次结构

丈夫：注意上面的 Car类，它有两个属性，且都是抽象类型(接口)而非实体的。

引擎和车轮是可插拔的，这样汽车能接受任何实现了声明接口的对象，且 Car 类无需任何改动。

妻子：所以，如果代码不遵循依赖倒置，就有下面的风险：

• 使用低层级类会破环高层级代码；
• 当低层级的类变化时，需要太多时间和代价来修改高层级代码；
• 代码可复用性不高

丈夫：亲爱的，你说到点子上了！