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

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

一、原理介绍

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. js 的七大原则--单一原则、开闭原则、替换原则(一)

    一.前言: js 的七大设计原则: 1.单一原则 2.开闭原则 3.里氏替换原则 4.依赖倒转原则 5.接口隔离原则 6.合成复用原则 7.迪米尔法则 二.单一原则 1.定义:单一原则就是一个对象或者 ...

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

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

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

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

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

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

随机推荐

  1. Httpsqs的安装以及安装过程错误的解决方法 转

    需求 :进行商品搜索的时候,要从索引中进行搜索,由于后台要更新商品和插入商品,当时考虑到了怎么来插入新的索引和更新索引的问题,通过讨论,大家决定用Httpsqs这个消息中间来通知插入新索引和删除索引最 ...

  2. ZOJ 3747 - Attack on Titans (递推)

    题意:有三个兵种R,G,C,选取N个排成一列,要求G至少有M个连续的,R至多有K个连续的,问有多少种排列方式. 此题与UVa 10328 - Coin Toss非常相似,都是问某个字符连续出现的种数. ...

  3. 追索权 Eclipse + NDK error: stray '\24' in program

    [size=16px][b][color=#FF0000]追索权 Eclipse + NDK  error: stray '\24' in program[/color][b][/b][/b][/si ...

  4. RDMA调研报告&一点随笔

    计算所科研实践随笔 被淹没在论文海里的两个星期. 早上7:10分起床,草草洗漱,7:30出发,开始漫长的1小时通勤.从地铁站的安检口起,队便排的极长,让人看得头皮发麻.下到了轨道旁稍好,但每趟呼啸而来 ...

  5. 五:Java之Vector类专题

    据说期末考试要考到Vector 这个类,出于复习须要在这里就要好好整理下这个类了. 一.基本概念 Vector 是可实现自己主动增长的对象数组. java.util.vector提供了向量类(vect ...

  6. 添加MD5 密码加密

        编辑 /etc/grub/grub.conf 配置文件 password = 123456 password --md5 $5$H.........SS grub-crypt  --md5   ...

  7. ArcGIS API for JavaScript 入门教程[1] 渊源

    ->对于萌新,你可能需要了解一下这个东西是什么 ->对于已经知道要用这个东西的开发者,你可能需要了解一下它的底层机制 不针对大牛.龟速更新ing. 转载注明出处.博客园&CSDN& ...

  8. [C#.net]获取文本文件的编码,自动区分GB2312和UTF8

    昨天生产突然反馈上传的结果查询出现了乱码,我赶紧打开后台数据库,发现果真有数据变成了乱码.这个上传程序都运行3个多月了,从未发生乱码现象,查看程序的运行日志,发现日志里的中文都变成了乱码,然后对比之前 ...

  9. hive建表报错:Specified key was too long; max key length is 767 bytes,hadoophive

    情况描述 Hive建表时报错,元数据存储在mysql中. 报错信息 如下: FAILED: Execution Error, bytes com.mysql.jdbc.exceptions.jdbc4 ...

  10. bat、sh等批处理文件(脚本文件)

    批处理文件(batch file):也被称为批处理程序或脚本,可以简化日常或重复性任务.本质是无格式的文本文件,它包含一条或多条命令.(1).bat是dos下的批处理文件,在window系统上执行的文 ...