前言:这篇继续来看看开闭原则。废话少说,直接入正题。

软件设计原则系列文章索引

一、原理介绍

1、官方定义

开闭原则,英文缩写OCP,全称Open Closed Principle。

原始定义:Software entities (classes, modules, functions) should be open for extension but closed for modification。

字面翻译:软件实体(包括类、模块、功能等)应该对扩展开放,但是对修改关闭。

2、自己理解

2.1、原理解释

  • 对扩展开放。模块对扩展开放,就意味着需求变化时,可以对模块扩展,使其具有满足那些改变的新行为。换句话说,模块通过扩展的方式去应对需求的变化。
  • 对修改关闭。模块对修改关闭,表示当需求变化时,关闭对模块源代码的修改,当然这里的“关闭”应该是尽可能不修改的意思,也就是说,应该尽量在不修改源代码的基础上面扩展组件。

2.2、为什么要“开”和“闭”

一般情况,我们接到需求变更的通知,通常方式可能就是修改模块的源代码,然而修改已经存在的源代码是存在很大风险的,尤其是项目上线运行一段时间后,开发人员发生变化,这种风险可能就更大。所以,为了避免这种风险,在面对需求变更时,我们一般不修改源代码,即所谓的对修改关闭。不允许修改源代码,我们如何应对需求变更呢?答案就是我们下面要说的对扩展开放。

通过扩展去应对需求变化,就要求我们必须要面向接口编程,或者说面向抽象编程。所有参数类型、引用传递的对象必须使用抽象(接口或者抽象类)的方式定义,不能使用实现类的方式定义;通过抽象去界定扩展,比如我们定义了一个接口A的参数,那么我们的扩展只能是接口A的实现类。总的来说,开闭原则提高系统的可维护性和代码的重用性。

二、场景示例

1、对实现类编程,你死得很惨

下面就结合之前博主在园子里面看到的一个使用场景来一步步呈现使用实现类编程的弊端。

场景说明:马上中秋节了, **公司希望研发部门研发一套工具,实现给公司所有员工发送祝福邮件。

接到开发需求,研发部立刻开会成立研发小组,进入紧张的开发阶段,经过1个月的艰苦奋战,系统顺利上线。代码实现如下:

1.1 EmailMessage工具类

namespace Utility
{
    //发送邮件的类
    public class EmailMessage
    {
        //里面是大量的SMTP发送邮件的逻辑

        //发送邮件的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("Email节日问候:" + strMsg);
        }
    }
}

1.2 MessageService服务

namespace Service
{
    public class MessageService
    {
        private EmailMessage emailHelper = null;
        public MessageService()
        {
            emailHelper = new EmailMessage();
        }

        //节日问候
        public void Greeting(string strMsg)
        {
            emailHelper.SendMessage(strMsg);
        }
    }
}

1.3 业务调用模块

    class Program
    {
        static void Main(string[] args)
        {
            Service.MessageService oService = new Service.MessageService();
            oService.Greeting("祝大家中秋节快乐。");

            Console.ReadKey();
        }
    }

一切都很顺利,系统也得到公司好评。

日复一日,年复一年,随着时间的推移,公司发现邮件推送的方式也存在一些弊病,比如某些网络不发达地区不能正常地收到邮件,并且在外出差人员有时不能正常收到邮件。这个时候公司领导发现短信推送是较好的解决办法。于是乎,需求变更来了:增加短信推送节日祝福的功能,对于行政部等特殊部门保留邮件发送的方式。

研发部的同事们虽然已有微言,但是没办法,也只有咬着牙忙了,于是代码变成了这样。

1.1 工具类里面增加了发送短信的帮助类

namespace Utility
{
    //发送邮件的类
    public class EmailMessage
    {
        //里面是大量的SMTP发送邮件的逻辑

        //发送邮件的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("Email节日问候:" + strMsg);
        }
    }

    //发送短信的类
    public class PhoneMessage
    {
        //手机端发送短信的业务逻辑

        //发送短信的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("短信节日问候:" + strMsg);
        }
    }

}

1.2 MessageService服务里面增加了一个枚举类型MessageType判断是哪种推送方式

namespace Service
{
    public enum MessageType
    {
        Email,
        Phone
    }

    public class MessageService
    {
        private EmailMessage emailHelper = null;
        private PhoneMessage phoneHelper = null;
        private MessageType m_oType;
        public MessageService(MessageType oType)
        {
            m_oType = oType;
            if (oType == MessageType.Email)
            {
                emailHelper = new EmailMessage();
            }
            else if (oType == MessageType.Phone)
            {
                phoneHelper = new PhoneMessage();
            }
        }

        //节日问候
        public void Greeting(string strMsg)
        {
            if (m_oType == MessageType.Email)
            {
                emailHelper.SendMessage(strMsg);
            }
            else if (m_oType == MessageType.Phone)
            {
                phoneHelper.SendMessage(strMsg);
            }
        }
    }
}

1.3 业务调用模块

    class Program
    {
        static void Main(string[] args)
        {
            Service.MessageService oEmaliService = new Service.MessageService(Service.MessageType.Email);
            oEmaliService.Greeting("祝大家中秋节快乐。");

            Service.MessageService oPhoneService = new Service.MessageService(Service.MessageType.Phone);
            oPhoneService.Greeting("祝大家中秋节快乐。");
            Console.ReadKey();
        }
    }

经过一段时间的加班、赶进度。终于大功告成。

随着公司的不断发展,很多产品、平台都融入了微信的功能,于是乎公司领导又希望在保证原有功能的基础上增加微信的推送方式。这个时候研发部的同事们就怨声载道了,这样一年改一次,何时是个头?并且随着时间的推移,研发部员工可能发生过多次变换,现在维护这个系统的员工早已不是当初的开发者,在别人的代码上面改功能,做过开发的应该都知道,简直苦不堪言,因为你不知道别人哪里会给你埋一个“坑”。并且在现有代码上面改,也存在很大的风险,即使做好之后所有的功能都必须重新经过严格的测试。

事情发展到这里,就可以看出使用实现类去编程,你会因为需求变更而死得很惨,这个时候我们就能看出遵守开闭原则的重要性了,如果这个系统设计之初就能考虑这个原则,所有的可变变量使用抽象去定义,可能效果截然不同。

2、对抽象编程,就是这么灵活

如果项目设计之初我们定义一个ISendable接口,我们看看效果怎样呢?

2.1 工具类

namespace IHelper
{
    public interface ISendable
    {
        void SendMessage(string strMsg);
    }
}
namespace Utility
{//发送邮件的类
    public class EmailMessage:ISendable
    {
        //里面是大量的SMTP发送邮件的逻辑

        //发送邮件的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("Email节日问候:" + strMsg);
        }
    }

    //发送短信的类
    public class PhoneMessage:ISendable
    {
        //手机端发送短信的业务逻辑

        //发送短信的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("短信节日问候:" + strMsg);
        }
    }

    //发送微信的类
    public class WeChatMessage:ISendable
    {
        //微信消息推送业务逻辑

        //发送微信消息的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("短信节日问候:" + strMsg);
        }
    }
}

2.2 MessageService服务

namespace Service
{
    public class MessageService
    {
        private ISendable m_oSendHelper = null;
        public MessageService(ISendable oSendHelper)
        {
            m_oSendHelper = oSendHelper;
        }

        //节日问候
        public void Greeting(string strMsg)
        {
            m_oSendHelper.SendMessage(strMsg);

        }
    }
}

2.3 业务调用模块

    class Program
    {
        static void Main(string[] args)
        {
            var strMsg = "祝大家中秋节快乐。";
            ISendable oEmailHelper = new EmailMessage();
            Service.MessageService oEmaliService = new Service.MessageService(oEmailHelper);
            oEmaliService.Greeting(strMsg);

            ISendable oPhoneHelper = new PhoneMessage();
            Service.MessageService oPhoneService = new Service.MessageService(oPhoneHelper);
            oPhoneService.Greeting(strMsg);

            ISendable oWeChatHelper = new WeChatMessage();
            Service.MessageService oWeChatService = new Service.MessageService(oWeChatHelper);
            oWeChatService.Greeting(strMsg);
            Console.ReadKey();
        }
    }

设计分析:在MessageService服务类中,我们定义了ISendable的接口变量m_oSendHelper,通过这个接口变量,我们就能很方便的通过扩展去应对需求的变化,而不必修改原来的代码。比如,我们现在再增加一种新的推送方式,对于我们的MessageService服务类来说,不用做任何修改,只需要扩展新的推送消息的工具类即可。从需要抽象的角度来说,开闭原则和依赖倒置原则也有一定的相似性,不过博主觉得,开闭原则更加偏向的是使用抽象来避免修改源代码,主张通过扩展去应对需求变更,而依赖倒置更加偏向的是层和层之间的解耦。当然,我们也不必分得那么细,往往,一个好的设计肯定是遵循了多个设计原则的。

上面的设计,很好的解决了MessageService服务类中的问题,但是对于调用方(比如上文中的Main函数里面),很显然是违背了依赖倒置原则的,因为它既依赖接口层ISendable,又依赖接口实现层EmailMessage、PhoneMessage等。这肯定是不合适的。我们引入MEF,稍作修改。

namespace Utility
{
    //发送邮件的类
    [Export("Email", typeof(ISendable))]
    public class EmailMessage:ISendable
    {
        //里面是大量的SMTP发送邮件的逻辑

        //发送邮件的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("Email节日问候:" + strMsg);
        }
    }

    //发送短信的类
    [Export("Phone", typeof(ISendable))]
    public class PhoneMessage:ISendable
    {
        //手机端发送短信的业务逻辑

        //发送短信的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("短信节日问候:" + strMsg);
        }
    }

    //发送微信的类
    [Export("WeChat", typeof(ISendable))]
    public class WeChatMessage:ISendable
    {
        //微信消息推送业务逻辑

        //发送微信消息的方法
        public void SendMessage(string strMsg)
        {
            Console.WriteLine("短信节日问候:" + strMsg);
        }
    }
}

Main函数里面

    class Program
    {
        [Import("Email",typeof(ISendable))]
        public ISendable oEmailHelper { get; set; }

        [Import("Phone", typeof(ISendable))]
        public ISendable oPhoneHelper { get; set; }

        [Import("WeChat", typeof(ISendable))]
        public ISendable oWeChatHelper { get; set; }

        static void Main(string[] args)
        {
            //使用MEF装配组件
            var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
            var container = new CompositionContainer(catalog);
            var oProgram = new Program();
            container.ComposeParts(oProgram);

            var strMsg = "祝大家中秋节快乐。";
            Service.MessageService oEmaliService = new Service.MessageService(oProgram.oEmailHelper);
            oEmaliService.Greeting(strMsg);

            Service.MessageService oPhoneService = new Service.MessageService(oProgram.oPhoneHelper);
            oPhoneService.Greeting(strMsg);

            Service.MessageService oWeChatService = new Service.MessageService(oProgram.oWeChatHelper);
            oWeChatService.Greeting(strMsg);
            Console.ReadKey();
        }
    }

如果你使用Unity,直接用配置文件注入的方式更加简单。

三、总结

至此开闭原则的示例就基本完了。文中观点有不对的地方,欢迎指出,博主在此多谢了。如果园友们觉得本文对你有帮助,请帮忙推荐,博主将继续努力~~

C#软件设计——小话设计模式原则之:开闭原则OCP的更多相关文章

  1. C#软件设计——小话设计模式原则之:依赖倒置原则DIP

    前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”, ...

  2. C#软件设计——小话设计模式原则之:单一职责原则SRP

    前言:上篇C#软件设计——小话设计模式原则之:依赖倒置原则DIP简单介绍了下依赖倒置的由来以及使用,中间插了两篇WebApi的文章,这篇还是回归正题,继续来写写设计模式另一个重要的原则:单一职责原则. ...

  3. C#软件设计——小话设计模式原则之:接口隔离原则ISP

    前言:有朋友问我,设计模式原则这些东西在园子里都讨论烂了,一搜一大把的资料,还花这么大力气去整这个干嘛.博主不得不承认,园子里确实很多这方面的文章,并且不乏出色的博文.博主的想法是,既然要完善知识体系 ...

  4. 设计原则:开-闭原则(Open-Closed Principle, OCP)

    开-闭原则就是软件实体应当对扩展开放,对修改关闭.(Software entities should be open for extension,but closed for modification ...

  5. 7.10 其他面向对象设计原则1: 开-闭原则OCP

    其他面向对象设计原则1: 开-闭原则OCP  Open-Closed Principle (OCP)5.1 设计变坏的前兆 Signs of Rotting Design  僵硬性 Rigidit ...

  6. 设计模式笔记:开闭原则(OCP,The Open-Closed Principle)

    1. 开闭原则概述 开闭原则(OCP,The Open-Closed Principle)两个主要特征: (1)对扩展开放(open for extension):模块的行为的可以扩展的,当应用的需求 ...

  7. 【设计模式】之开闭原则(OCP)

    开闭原则是面向对象设计的一个重要原则,其定义如下: 开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭.即软件实体应尽量在不修改原有代码的情况下进 ...

  8. C#设计模式系列:开闭原则(Open Close Principle)

    1.开闭原则简介 开闭原则对扩展开放,对修改关闭,开闭原则是面向对象设计中可复用设计的基石. 2.开闭原则的实现 实现开闭原则的关键就在于抽象,把系统的所有可能的行为抽象成一个抽象底层,这个抽象底层规 ...

  9. 深入理解JavaScript系列(7):S.O.L.I.D五大原则之开闭原则OCP

    前言 本章我们要讲解的是S.O.L.I.D五大原则JavaScript语言实现的第2篇,开闭原则OCP(The Open/Closed Principle ). 开闭原则的描述是: Software ...

随机推荐

  1. 由一条Linux的grep命令说起

    今天在开发的时候,看到同事使用了这样的一条linux命令 grep 'class YourClass' -rwi * |grep -v svn 想到了 grep命令的,几个参数. -r 明确要求搜索子 ...

  2. chrome shortcutkey

    按下Shift并点击链接 – 在新窗口打开链接. Ctrl+ – 切换到最后一个标签. Ctrl+Shift+V – 将剪切板中的内容无格式粘贴(举个例子,将你从网页中复制的HTML格式内容粘贴为纯文 ...

  3. Thinking in Java——笔记(10)

    Inner Classes It allows you to group classes that logically belong together and to control the visib ...

  4. 小谈pointer和relation

    在apicloud的数据库中,pointer和relation是在很难让人理解. 通过不断的实践,终于有点明白了. pointer和relation作用:在nosql数据库中实现表之间的关联 首先来说 ...

  5. 根据多年经验整理的《互联网MySQL开发规范》

    一.基础规范 使用 INNODB 存储引擎 表字符集使用 UTF8  所有表都需要添加注释 单表数据量建议控制在 5000W 以内 不在数据库中存储图⽚.文件等大数据 禁止在线上做数据库压力测试 禁⽌ ...

  6. JQuery面试题答案

    jQuery面试题答案 转自:http://blog.csdn.net/zhangpei_xf/article/details/8822021 一.Jquery测试题 下面哪种不是jquery的选择器 ...

  7. [uwp开发]数据绑定那些事(2)

    接着上一篇来侃. 二.实体到控件之间的绑定 这儿不知道用实体这个词恰不恰当,凑活着理解就行了.他可以是一个类实例,也可以是一个集合. 所以,相应的我们就引入两个Demo,第一个介绍用简单的类作为作为数 ...

  8. 剑指offer--面试题10--相关

    题目一:判断一个整数是不是2的n次幂 实现大概如下: int main() { ; )) == ) //重要!! std::cout<<"YES!"<<st ...

  9. myeclipse 的 working set

    想必大家的myeclipse会有很多工程看的和不方便,那么怎么让它看的简洁一点呢,使用working set 会让你的目录看起来没有那么的多. 首先是怎么创建 working set  ,在新建时选择 ...

  10. [转]机器学习——C4.5 决策树算法学习

    1. 算法背景介绍 分类树(决策树)是一种十分常用的分类方法.它是一种监管学习,所谓监管学习说白了很简单,就是给定一堆样本,每个样本都有一组属性和一个类别,这些类别是事先确定的,那么通过学习得到一个分 ...