如何向妻子解释设计模式-白红宇

如何向妻子解释设计模式

阅读量：5904 次

发布时间：2019-06-19

本文共 6024 字，大约阅读时间需要 20 分钟。

源自：http://www.cnblogs.com/niyw/archive/2011/05/30/2062071.html

简介

　　自上篇翻译<>后收到了很好的反应。故特继续翻译作者的<>一文，以飨读者。在此文中，作者依旧通过与妻子浅显易懂的对话，向读者解释了什么是设计模式。

设计模式是什么?

Shubho:通过我们关于面向对象设计原则（OODP，即SOLID原则）的对话，我想你已经对面向对象设计原则（OODP）有了基本的认识。希望你不要介意我把对话分享到博客上。你可以在这找到它：>.

设计模式是这些原则在某些特定公共场景下标准化的应用，接下来让我们通过一些例子学习什么是设计模式。

Farhana: 当然，我喜欢例子。

Shubho: 让我们以汽车为例讨论一下。汽车是一个很复杂的对象，由成千上万的其它对象组成，如发动机，车轮，方向盘，车座，车体等等其他不同的部分或部件。

汽车部件

当装配汽车时，制造商需要集中并装配这些更小的自成汽车子系统的不同部件。而这些不同的小部件同样也是复杂的对象，其它制造商同样要生产并组装它们。在生产汽车时，汽车公司并不会为怎么生产组装这些部件操心（前提是他们要确保这些对象/设备的质量）。当然，汽车制造商更加关心怎么装配这些不同部件以便能生产不同型号的汽车。

通过遵循不同的设计，组装不同的部件，生产不同型号的汽车

Farhana: 汽车制造公司必须有如何生产不同型号汽车的设计图或蓝图，对吗？

Shubho: 当然，并且这些设计都是良好的，他们花费大量的时间和精力来做这些设计。一旦设计完成，生产汽车就仅仅是照葫芦画瓢了。

Farhana: 嗯。如果事先有一些好的设计，就能在短时间内遵照这些设计生产不同产品，并且制造商在每次生产某一个型号产品时就不需要重新设计或重新发明车轮，他们只需要按照已有的设计办事就行了。

生产不同型号产品（汽车）的不同设计图

Shubho: 你抓到重点了。现在假设我们是软件生产商，我们使用基于需求而来的不同组件或功能构建各种不同的软件程序。当生产这些不同软件系统时，我们常常需要为一些不同软件系统中存在的相同情况开发代码，对吗？

Farhana: 是的，在开发不同软件程序时经常遇到相同的设计问题。

Shubho: 我们尝试使用面向对象的方式开发软件，并尝试应用OOPD来让代码能易于维护，可复用，可扩展。无论什么时候，当我们遇到这些设计问题时，如果我们有一组经过谨慎开发，良好测试的对象以供使用会不会更好呢？

Farhana: 是的，这样能够节省时间，生产出更好的软件，且利于以后维护。

Shubho: 很好！从设计上来说，它的好处是你不需要开发那些对象。经过多年发展，人们已经遇到过一些类似的设计问题，并已经形成有一些公认的，良好的已标准化的设计方案。我们称之为设计模式。

我们一定好感谢四人组，他们在《设计模式：可复用面向对象软件设计》中总结出了23种基本的设计模式。四人组由Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides组成。实际中有很多面向对象设计模式，但这23种模式被公认为是所有其他设计模式的基础。

Farhana: 我能发明一个新的模式吗？这可能吗？

Shubho: 当然，亲爱的，为什么不能呢？！设计模式不是由科学家发明创造的。它们是被发现找到的。这意味着任何通用问题场景中都有一些好的设计方案在那。如果我们能够指出一个能够解决一个新的设计相关问题的面向对象设计，那么这将会是一个由我们定义的新的设计模式。谁知道呢？！如果我们发现找到一些设计模式，或许将来有一天人们会称我们为二人组，哈哈。

Fahana: :)

我们将如何学习设计模式？

Shubho: 我一直认为例子是学习的最好途径。在我们的学习方法中，我们不会先讨论理论后讨论实现。我认为这是很糟糕的方式。设计模式不是基于理论的发明。事实上，问题场景首先出现，其次是基于这些问题的来龙去脉和需求，然后是一些设计方案的演化，最后其中的一些被标准化为模式。所以对每一个我们讨论的设计模式，我们将尝试理解并分析一些现实生活中的例子，然后一步步尝试归纳一个设计，并最后总结一些与某些模式匹配设计。设计模式就是在这些相似过程中发现的。你认为呢？

Farhana:我想这种方式对我更有用。如果我能通过分析问题和归纳方案得出设计模式，我就不用死记那些设计模式和定义了。请按照你的方式继续。

一个常见的设计问题和它的解决方案

Shubho: 让我们考虑下面的场景：

我们房间里有些电器（电灯，风扇等）。这些设备按照某些方式布局，并由开关控制。任何时候你都能替换或排查一个电器而不用碰到其他东西。例如，你可以换一个电灯而不需要换开关。同样，你可以换一个开关或排查它而不需要碰到或替换相应的电灯或风扇；甚至你可以用把电灯连接到风扇的开关上，把风扇连到电灯的开关上，而不需要碰到开关。

电器：风扇和电灯

风扇和电灯的两种不同开关，一个普通点，另一个别致点

Farhana: 是的，但就是这样子，对吗？

Shubho: 是的，确实如此，就该如此布局。当不同东西联系在一起时，它们应该按照一定方式联系：修改或替换一个系统时不会影响到另一个，或者说即便有，也应该最小化。这能够让你的系统易于管理，且成本低。想想一下，如果改一下房间里的灯同时需要改开关，你会乐意在你房子上花钱并安装这个系统吗？

Farhana: 当然不会。

Shubho: 现在，让我们思考一下电灯或风扇如何连接到开关上才能达到改变一个不会影响到另一个。你认为该如何？

Farhana: 用电线!

Shubho: 很好。把电灯/风扇和开关联系到一起的是电线和电器布局。我们可以它们看做不同系统间相互联系的桥梁。其基本的思想是，一个事物不能和另一外一个事物直接联系。当然啦，它们应当通过某些桥梁或接口联系在一起。用软件术语来说，这叫“松耦合”。

Farhana: 我知道了。

Shubho: 现在，让我们尝试推断在电灯/风扇和开关例子中的几个关键问题，并尝试推断它们是如何设计并联系起来的。

Farhana: 好，我们试一下。

例子中我们有开关，可能有几种开关，如普通的开关，漂亮的开关，但通常来说它们还是开关，并且每种开关都能够打开和关闭。

所以下面我们会有一个开关基类Switch：

public class Switch {

public void On() {

//打开开关

}

public void Off() {

//关闭开关

}

接下来我们可以有一些具体的开关，例如一个漂亮开关，一个普通开关等等，当然，我们会让类FancySwitch和NormalSwitchnd继承类Switch：

public class NormalSwitch : Switch {

}

public class FancySwitch : Switch {

}

这里的两个具体类有自己的特征和行为，只是此时此刻，我们简单化以下。

Shubho: 非常棒，接下来电灯和风扇怎么办？

Farhana: 我试试. 根据OODP的开放闭合原则，我们知道只要可能，就应该尝试抽象，对吗？

Shubho: 对

Farhana: 跟开关不一样，风扇和电灯等是两种不同的事物。对于开关，我们能够使用一个开关基类Switch，但风扇和电灯是两个不同的事物，相比定义一个基类，接口可能更合适。一般来说，他们都是电器。所以我们可以定义一个接口，如IElectricalEquipment，作为对电灯和风扇的抽象，可以吗？

Shubho: 可以

Farhana: 好，每种电器都有些相同的功能。他们能够打开和关闭。所以接口可能如下：

public interface IElectricalEquipment {

void PowerOn(); //每种电器都能打开

void PowerOff(); //每种电器都能关闭

}

Shubho: 太好了，你很善于抽象东西。现在我们需要一座桥梁。在现实中，电线是桥梁。在我们对象设计中，开关知道如何打开和关闭电器，电器以某种方式联系到开关。这里我们没有电线，让电器连接到开关的唯一方式是封装。

Farhana: 是的，但开关不能直接知道风扇或电灯。开关应当知道一个电器IElectricalEquipment能够打开或关闭。这意味着，ISwitch应该有一个IElectricalEquipment实例，对吗？

Shubho: 对，对风扇或电灯的封装的实例是一个桥梁。所以让我们修改Switch类以便封装一个电器：

public class Switch {

public IElectricalEquipment equipment {

get;

set;

}

public void On() {

//开关打开

}

public void Off() {

//开关关闭

}

Farhana: 明白。让我们定义真实的电器：风扇和电灯。如我所见，一般来说它们都是电器，所以它们都简单实现了IElectricalEquipment接口。

下面是风扇类:

public class Fan : IElectricalEquipment {

public void PowerOn() {

Console.WriteLine("风扇打开");

}

public void PowerOff() {

Console.WriteLine("风扇关闭");

}

下面是电灯类:

public class Light : IElectricalEquipment {

public void PowerOn() {

Console.WriteLine("电灯打开");

}

public void PowerOff() {

Console.WriteLine("电灯关闭");

}

Shubho:太好了。现在让开关工作。当开关打开关闭的时候它应当能够打开关闭电器（它连接到的）。

这里的关键点是：

当开关按下开时，连接的电器也应该打开。

当开关按下关时，连接的电器也应该关闭。

大致的代码如下:

static void Main(string[] args) {

//构造电器设备:风扇,开关

IElectricalEquipment fan = new Fan();

IElectricalEquipment light = new Light();

//构造开关

Switch fancySwitch = new FancySwitch();

Switch normalSwitch = new NormalSwitch();

//把风扇连接到开关

fancySwitch.equipment = fan;

//开关连接到电器,那么当开关打开或关闭时电器应该打开/关闭

fancySwitch.On();

fancySwitch.Off();

//把电灯连接到开关

fancySwitch.equipment = light;

fancySwitch.On(); //打开电灯

fancySwitch.Off(); //关闭电灯

}

Farhana: 明白。开关的On()方法应当内部调用电器的TurnOn()方法，Off()方法应当内部调用TurnOff()方法，所以开关类Switch应如下：

public class Switch {

public IElectricalEquipment equipment {

get;

set;

}

public void On() {

Console.WriteLine("开关打开");

equipment.PowerOn();

}

public void Off() {

Console.WriteLine("开关关闭");

equipment.PowerOff();

}

Shubho: 很好。这自然允许你把风扇从一个开关接到另一个上。不过你看，反过来也可以。这意味着你可以改变风扇或电灯的开关而不需要碰到风扇或电灯。例如，你可以很轻松的把点灯的开关从FancySwitch换到NormalSwitch上，如下：

normalSwitch.equipment = light;

normalSwitch.On(); //打开电灯

normalSwitch.Off(); //关闭电灯

你看，连接一个抽象电器到一个开关（通过封装）能够让你改变开关和电器而不会对对方产生影响。这个设计是优雅的，良好的。四人组为该模式取名为：桥接模式。

Farhana: 太棒了。我想我明白这个了。从根本上说，两个系统不应当直接联系或依赖与对方。当然，他们应该联系或依赖于抽象（如依赖倒置原则和开放闭合原则所讲），所以他们是松耦合的，因此我们可以在需要时改变我们的实现而不会对系统其他部分产生过多影响。

Shubho: 你理解了，亲爱的.我们看下桥接模式的定义：

"将抽象部分与实现部分分离，使它们都可以独立的变化"

你看我们的实现完美遵循该定义。如果你有一个类设计器（如Visual Studio或其他支持该功能的IDE环境），你会看到类似的如下类图：

桥接模式类图

在这里， Abstraction 是开关基类Switch。 RefinedAbstraction 是具体开关类 (FancySwitch, NormalSwitch 等等。)。 Implementor 是电器接口IElectricalEquipment。ConcreteImplementorA 和ConcreteImplementorB 是电灯类Light和风扇类Fan。