[设计模式原则]开闭原则(Open - ClosedPrinciple, OCP)

对扩展开放，对修改关闭（设计模式的核心原则）

设计模式重在设计阶段，封装变化点，预留扩展。而不是在需求变化时再来讨论类的继承扩展组合修改等等。

用抽象构建框架，用实现扩展细节。

框架在设计阶段就确认，细节在后期变化修改进行扩展。

在设计阶段就考虑好变化点，把变化点抽象并封装，把整个框架骨骼搭起来。后期需求变化的时候，扩展抽象的变化点，对现有框架骨骼不会造成影响。

其他五个原则丰满了开闭原则

单一职责原则告诉我们实现类要职责单一；-〉类

里氏替换原则告诉我们不要破坏继承体系；-〉类和父类

迪米特法则告诉我们要降低耦合；-〉类和世界类

依赖倒置原则告诉我们要面向接口编程；-〉类和接口

接口隔离原则告诉我们在设计接口的时候要精简单一；-〉接口

 

常用于实现的设计模式主要有Template Method模式和Strategy模式。

 

假设是银行处理流程，针对不同客户，假定银行是这么处理的

代码一：

class BusyBankStaff
    {
        private BankProcess bankProc = new BankProcess();
        public void HandleProcess(Client client)
        {
            switch (client.ClientType)
            {
                case "存款用户":
                    bankProc.Deposit();
                    break;case "取款用户":
                    bankProc.DrawMoney();
                    break;
            }
        }
}

 

其实这么写完全没问题

语法没问题

效率也挺好的

老师也是这么教的

问题来源于变化。

程序在客户眼里是一个个界面

底层代码架构对于客户毫无意义，就像01010101010101对于你我毫无意义

如果客户没有新的需求，跟客户说变更架构带来的好处，同样毫无意义

意义在于，变更界面，添加界面，以及这些变更所需要的时间

对的，时间

时间是金钱

大家都在跟时间赛跑

有人说时间是个假像

因为时间不存在

但是时间是金钱

现在，客户有需求了，

第一个需求，要添加一个界面，一天后使用，一般情况很好解决，程序员无敌，分分钟搞定

第二个需求，不能对现有系统现有功能造成影响，这个没人能够确定，比如，蝴蝶效应，程序是一个世界，模块是一个世界，类是一个世界。需求，改变了规则，世界会对此作出反应。客户希望世界添加新的元素，比如，有吸血鬼的存在。客户的要求很简单，这个世界要出现吸血鬼。这是唯一的需求，可是程序员不要简单认为这是唯一的需求。我们应该认识到，这个世界不能因为出现吸血鬼而出现越来越多的吸血鬼，然后过了几天，客户将看到一个除了吸血鬼没有别的存在的世界？这不是我们想要的。吸血鬼的存在不能对现有世界造成太大的影响，他们也需要遵守既定世界的规则，并维持既定世界的既定运行模式。

回到银行这个问题

现在需求增加一个用户用于 转账用户，如果代码一是原始代码，那么如下修改，红色为新增业务

代码二：

class BusyBankStaff
    {
        private BankProcess bankProc = new BankProcess();
        public void HandleProcess(Client client)
        {
            switch (client.ClientType)
            {
                case "存款用户":
                    bankProc.Deposit();
                    break;
                case "取款用户":
                    bankProc.DrawMoney();
                    break;
                case "转账用户":
                    bankProc.Transfer();
                    break;
            }
        }
}


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

 

这么写完全没有问题

不过我们注意到，修改代码在方法HandleProcess里，HandleProcess在类BusyBankStaff里。

或者这么说

你改变了HandleProcess这个小世界，也就是改变了BusyBankStaff这个世界，然后，外面还有别的模块等等越来越大的世界。

如果HandleProcess是个独立的世界，或者如果HandleProcess是个封装完整良好的方法，那么不需要考虑改变对其余世界带来的影响，同时有单元测试来保证这个小世界本身的稳定。

如果这个方法封装的不够好，修改波及到了类的其余部分，那么至少，这个类要封装的够好才能保证对类外面的世界影响够小，

如果这个类封装的不够好，修改波及到了别的类，那么至少，这个模块要封装的够好才能。。。扒拉扒拉

你看，改变，往往不是一件简单的事情

聪明的人才能看到改变并不可怕，可怕的是不受控制的改变

时刻把改变造成的影响控制在尽可能小的范围内，这样才能快速增加新的需求（开发需要花时间），快速测量改变造成的影响（测试需要花时间），如果造成影响也可快速修复（修复需要花时间），这在软件升级中很重要。开闭原则，保证改变影响的范围尽可能小，这才是重点。

直接附上开闭原则的设计

代码三：

interface IBankProcess
    {
        void Process();
}

class DepositProcess : IBankProcess
    {
        public void Process()
        {
            // 办理存款业务
            throw new Exception("The method or operation is not implemented.");
        }
 }
class DrawMoneyProcess : IBankProcess
    {
        public void Process()
        {
            // 办理取款业务
            throw new Exception("The method or operation is not implemented.");
        }
 }

class EasyBankStaff
    {
        private IBankProcess bankProc = null;

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

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

 

对比代码二和代码三，业务处理分散到三个类中

当变化发生时，代码三需要的改动是新增转账业务类实现IBankProcess，在客户段传入转账用户。因为是新类，对现有业务类不造成影响。变化紧紧局限在新的小世界里。开发和测试都可以很快地进行。

 

参考：

开放封闭原则

设计模式六大原则（6）：开闭原则