开放封闭原则、 设计模式六大原则3：依赖倒置原则

2.3.1引言

无论如何，开放封闭原则（OCP，Open Closed Principle）都是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。

2.3.2引经据典

关于开放封闭原则，其核心的思想是：

软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

因此，开放封闭原则主要体现在两个方面：

对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。

对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对软件需求最经典的表白。从中透射出一个关键的意思就是，对于软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？

只有依赖于抽象。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。关于这两个原则，我们在本书的其他部分都有相应的论述，在应用反思部分将有深入的讨论。

对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。

2.3.3应用反思

站在银行窗口焦急等待的用户，在长长的队伍面前显得无奈。所以，将这种无奈迁怒到银行的头上是理所当然的，因为银行业务的管理显然有不当之处。银行的业务人员面对蜂拥而至的客户需求，在排队等待的人们并非只有一种需求，有人存款、有人转账，也有人申购基金，繁忙的业务员来回在不同的需求中穿梭，手忙脚乱的寻找各种处理单据，电脑系统的功能模块也在不同的需求要求下来回切换，这就是一个发生在银行窗口内外的无奈场景。而我每次面对统一排队的叫号系统时，都为前面长长的等待人群而叫苦，从梳理银行业务员的职责来看，在管理上他们负责的业务过于繁多，将其对应为软件设计来实现，你可以将这种拙劣的设计表示如图2-3所示。

按照上述设计的思路，银行业务员要处理的工作，是以这种方式被实现的：

class BusyBankStaff
    {
        private BankProcess bankProc = new BankProcess();
        // 定义银行员工的业务操作
        public void HandleProcess(Client client)
        {
            switch (client.ClientType)
            {
                case "存款用户":
                    bankProc.Deposit();
                    break;
                case "转账用户":
                    bankProc.Transfer();
                    break;
                case "取款户":
                    bankProc.DrawMoney();
                    break;
            }
        }
}

这种设计和实际中的银行业务及其相似，每个BusyBankStaff（“繁忙的”业务员）接受不同的客户要求，一阵手忙脚乱的选择处理不同的操作流程，就像示例代码中的实现的Switch规则，这种被动式的选择造成了大量的时间浪费，而且容易在不同的流程中发生错误。同时，更为严重的是， 再有新的业务增加时，你必须修改BankProcess中的业务方法，同时修改Switch增加新的业务，这种方式显然破坏了原有的格局，以设计原则的术语来说就是：对修改是开放的。

以这种设计来应对不断变化的银行业务，工作人员只能变成BusyBankStaff了。分析这种僵化的代码，至少有以下几点值得关注：银行业务封装在一个类中，违反单一职责原则；有新的业务需求发生时，必须通过修改现有代码来实现，违反了开放封闭原则。

解决上述麻烦的唯一办法是应用开放封闭原则：对扩展开放，对修改封闭。我们回到银行业务上看：为什么这些业务不能做以适应的调整呢？每个业务员不必周旋在各种业务选项中，将存款、取款、转账、外汇等不同的业务分窗口进行，每个业务员快乐地专注于一件或几件相关业务，就会轻松许多。综合应用单一职责原则来梳理银行业务处理流程，将职责进行有效的分离；而这样仍然没有解决业务自动处理的问题，你还是可以闻到僵化的坏味道在系统中弥漫。

应用开发封闭原则，可以给我们更多的收获，首先将银行系统中最可能扩展的部分隔离出来，形成统一的接口处理，在银行系统中最可能扩展的因素就是业务功能的增加或变更。对于业务流程应该将其作为可扩展的部分来实现，当有新的功能增加时，不需重新梳理已经形成的业务接口，然后再整个系统要进行大的处理动作，那么怎么才能更好的实现耦合度和灵活性兼有的双重机制呢？

答案就是抽象。将业务功能抽象为接口，当业务员依赖于固定的抽象时，对于修改就是封闭的；而通过继承和多态机制，从抽象体派生出新的扩展实现，就是对扩展的开放。

依据开放封闭原则，进行重构，新的设计思路如图2-4所示。

图2-4面向抽象的设计

按照上述设计实现，用细节表示为：

interface IBankProcess
    {
        void Process();
}

然后在隔离的接口上，对功能进行扩展，例如改造单一职责的示例将有如下的实现：

//按银行按业务进行分类

class DepositProcess : IBankProcess
   {
        IBankProcess Members
 }

 class TransferProcess : IBankProcess
   {
        IBankProcess Members
 }

 class DrawMoneyProcess : IBankProcess
  {
        IBankProcess Members
 }

这种思路的转换，会让复杂的问题变得简单明了，使系统各负其责，人人实惠。有了上述的重构，银行工作人员彻底变成一个EasyBankStaff（“轻松”的组织者）：

class EasyBankStaff
    {
        private IBankProcess bankProc = null;

        public void HandleProcess(Client client)
        {
            bankProc = client.CreateProcess();
            bankProc.Process();
        }
 }

银行业务可以像这样被自动地实现了：

class BankProcess
    {
        public static void Main()
        {
            EasyBankStaff bankStaff = new EasyBankStaff();
            bankStaff.HandleProcess(new Client("转账用户"));
        }
 }

你看，现在一切都变得轻松自在，匆忙中办理业务的人们不会在长长的队伍面前一筹莫展，而业务员也从繁琐复杂的劳动中解脱出来。当有新的业务增加时，银行经理不必为重新组织业务流程而担忧，你只需为新增的业务实现IBankProcess接口，系统的其他部分将丝毫不受影响，办理新业务的客户会很容易找到受理新增业务的窗口，如图2-5所示。

图2-5符合OCP的设计

对应的实现为：

class FundProcess : IBankProcess
    {
        IBankProcess Members
}

可见，新的设计遵守了开放封闭原则，在需求增加时只需要向系统中加入新的功能实现类，而原有的一切保持封闭不变的状态，这就是基于抽象机制而实现的开放封闭式设计。

然而，细心观察上述实现你会发现一个非常致命的问题：人们是如何找到其想要处理的业务窗口，难道银行还得需要一部分人力来进行疏导？然而确实如此，至少当前的设计必须如此，所以上述实现并非真正的业务处理面貌，实际上当前“轻松”的银行业务员，还并非真正的“轻松”，我们忽略了这个业务系统中最重要的一部分，就是用户。当前，用户的定义被实现为：

class Client
    {
        private string ClientType;

        public Client(string clientType)
        {
            ClientType = clientType;
        }

        public IBankProcess CreateProcess()
        {
            switch (ClientType)
            {
                case "存款用户":
                    return new DepositProcess();
                    break;
                case "转账用户":
                    return new TransferProcess();
                    break;
                case "取款用户":
                    return new DrawMoneyProcess();
                    break;
            }
            return null;
        }
    }

如果出现新增加的业务，你还必须在长长的分支语句中加入新的处理选项，switch的坏味道依然让每个人看起来都倒胃口，银行业务还是以牺牲客户的选择为代价，难道不能提供一个自发组织客户寻找业务窗口的机制吗？

我们把答案放在下一节2.4节“依赖倒置原则”，其中的设计原则就是用于解决上述问题的。我们对于银行业务的讨论，还会继续进行。

2.3.4规则建议

l开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。

l可以通过Template Method模式和Strategy模式进行重构，实现对修改封闭、对扩展开放的设计思路。

l封装变化，是实现开放封闭原则的重要手段，对于经常发生变化的状态一般将其封装为一个抽象，例如银行业务中的IBankProcess接口。

l拒绝滥用抽象，只将经常变化的部分进行抽象，这种经验可以从设计模式的学习与应用中获得。

设计模式六大原则（3）：依赖倒置原则

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。

问题由来：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。

解决方案：将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。

依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。

依赖倒置原则的核心思想是面向接口编程，我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的，母亲给孩子讲故事，只要给她一本书，她就可以照着书给孩子讲故事了。代码如下：

class Book{
	public String getContent(){
		return "很久很久以前有一个阿拉伯的故事……";
	}
}

class Mother{
	public void narrate(Book book){
		System.out.println("妈妈开始讲故事");
		System.out.println(book.getContent());
	}
}

public class Client{
	public static void main(String[] args){
		Mother mother = new Mother();
		mother.narrate(new Book());
	}
}

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……

运行良好，假如有一天，需求变成这样：不是给书而是给一份报纸，让这位母亲讲一下报纸上的故事，报纸的代码如下：

class Newspaper{
	public String getContent(){
		return "林书豪38+7领导尼克斯击败湖人……";
	}
}

这位母亲却办不到，因为她居然不会读报纸上的故事，这太荒唐了，只是将书换成报纸，居然必须要修改Mother才能读。假如以后需求换成杂志呢？换成网页呢？还要不断地修改Mother，这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了，必须降低他们之间的耦合度才行。

我们引入一个抽象的接口IReader。读物，只要是带字的都属于读物：

interface IReader{
	public String getContent();
}

Mother类与接口IReader发生依赖关系，而Book和Newspaper都属于读物的范畴，他们各自都去实现IReader接口，这样就符合依赖倒置原则了，代码修改为：

class Newspaper implements IReader {
	public String getContent(){
		return "林书豪17+9助尼克斯击败老鹰……";
	}
}
class Book implements IReader{
	public String getContent(){
		return "很久很久以前有一个阿拉伯的故事……";
	}
}

class Mother{
	public void narrate(IReader reader){
		System.out.println("妈妈开始讲故事");
		System.out.println(reader.getContent());
	}
}

public class Client{
	public static void main(String[] args){
		Mother mother = new Mother();
		mother.narrate(new Book());
		mother.narrate(new Newspaper());
	}
}

运行结果：

妈妈开始讲故事
很久很久以前有一个阿拉伯的故事……
妈妈开始讲故事
林书豪17+9助尼克斯击败老鹰……

这样修改后，无论以后怎样扩展Client类，都不需要再修改Mother类了。这只是一个简单的例子，实际情况中，代表高层模块的Mother类将负责完成主要的业务逻辑，一旦需要对它进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。

采用依赖倒置原则给多人并行开发带来了极大的便利，比如上例中，原本Mother类与Book类直接耦合时，Mother类必须等Book类编码完成后才可以进行编码，因为Mother类依赖于Book类。修改后的程序则可以同时开工，互不影响，因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。
在实际编程中，我们一般需要做到如下3点：

• 低层模块尽量都要有抽象类或接口，或者两者都有。
• 变量的声明类型尽量是抽象类或接口。
• 使用继承时遵循里氏替换原则。

依赖倒置原则的核心就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。