单一职责______开放封闭原则____依赖倒转”原则(DIP)

2.2  单一职责原则

2.2.1 引言

         一个优良的系统设计，强调模块间保持低耦合、高内聚的关系，在面向对象设计中这条规则同样适用，所以面向对象的第一个设计原则就是：单一职责原则（SRP，Single Responsibility Principle）。

         单一职责，强调的是职责的分离，在某种程度上对职责的理解，构成了不同类之间耦合关系的设计关键，因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。

2.2.2 引经据典

         关于单一职责原则，其核心的思想是：

                  一个类，最好只做一件事，只有一个引起它变化的原因。

    单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大的损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。

    因此，SRP原则的核心就是要求对类的改变只能是一个，对于违反这一原则的类应该进行重构，例如以Façade模式或Proxy模式分离职责，通过基本的方法Extract Interface、Extract Class和Extract Method进行梳理。

2.2.3 应用反思

         我们以一个常见的数据库管理系统为例来进行说明，通常情况下根据不同的权限进行数据删改查的系统比比皆是，然而正是这样一个比较的常见的需求场景，却存在着很多充满臭味的设计。一个违背SRP原则的设计看起来如图2-1所示。

图2-1 违背SRP的设计

         在以下设计中，DBManager类对数据库的操作和用户权限的判别封装在一个类中实现，一添加记录为例，其实现逻辑可以表示为：

public void Add()
    {
        if (GetPermission(m_id) == "CanAdd")
        {
            Console.WriteLine("管理员可以增加数据。");
        }
}

 

这显然是一个充满了僵化味道的实现，如果权限设置的规则发生改变，那就必须重新修改所有的数据库操作逻辑，在成千上万代码中搜索有可能带来隐患的代码，你必须选择将这种代码扫地出门。

在此，权限判断的职责和数据库操作的职责被无理的实现在一个类中，权限的规则变化和数据库操作的规则变化，都有可能引起DBManager修改当前代码。按照单一职责原则，一个类应该只有一个引起它改变的原因。所以我们选择以合适的方式来重构有缺陷的设计，在此显然可以通过实现一个Proxy模式来解决职责交叉的窘境，修改之后的设计思路如图2-2所示。

图2-2 职责分离的设计

以Proxy模式调整之后，有效实现了职责的分离，DBManager类只关注数据操作逻辑，而不用关心权限判断逻辑，在此仅以Add操作为例来说明：

public class DBManager : IDBAction
    {
        private string m_id = string.Empty;

        public DBManager(string id)
        {
            m_id = id;
        }

        IDBAction Members#region IDBAction Members

        public void Add()
        {
            // 执行数据增加
        }

        public bool Delete()
        {
            return false;
        }

        public void View()
        {
            throw new Exception("The method or operation is not implemented.");
        }

        #endregion
}

    而将权限的判断交给DBManagerProxy代理类来完成，例如：

public class DBManagerProxy : IDBAction
    {
        private IDBAction dbManager;

        public DBManagerProxy(IDBAction dbAction)
        {
            dbManager = dbAction;
        }

        public string GetPermission(string id)
        {
            return string.Empty;
        }

        IDBAction Members#region IDBAction Members

        public void Add()
        {
            if (GetPermission("") == "CanAdd")
            {
                dbManager.Add();
            }
        }

        public bool Delete()
        {
            throw new Exception("The method or operation is not implemented.");
        }

        public void View()
        {
            throw new Exception("The method or operation is not implemented.");
        }

        #endregion
    }

  通过代理，将数据操作和权限判断两个职责分离，而实际的数据操作由DBManager来执行，此时客户端的调用变得非常简单：

public class DBClient
    {
        static void Main(string[] args)
        {
            IDBAction dbManager = new DBManagerProxy(new DBManager("CanAdd"));
            dbManager.Add();
        }
 }

  在该例中，接口IDBAction其实实现了设计模式的另一个重要原则：依赖倒置，对此我们在后文有详细论述。在本例中，通过DBManagerProxy代理类实现了职责分离，DBManager类将仅有一个变化的原因，那就是数据操作的需求变更；而权限的变更和修改不对DBManager造成任何影响，体现了单一职责原则的基本精神。

2.2.4 规则建议

    关于单一职责原则，我们的建议是：

l  一个类只有一个引起它变化的原因，否则就应当考虑重构。

l  SRP由引起变化的原因决定，而不由功能职责决定。虽然职责常常是引起变化的轴线，但是有时却未必，应该审时度势。

l  测试驱动开发，有助于实现合理分离功能的设计。

l  可以通过Façade模式或Proxy模式进行职责分离。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zhongjiekangping/archive/2009/11/18/4827200.aspx

 

 

开放封闭原则

　　开放封闭原则（OCP，Open Closed Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。 　　关于开放封闭原则，其核心的思想是： 　　软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。 　　因此，开放封闭原则主要体现在两个方面： 　　对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。 　　对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。 　　“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对软件需求最经典的表白。从中透射出一个关键的意思就是，对于软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？ 　　只有依赖于抽象。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。关于这两个原则，我们在本书的其他部分都有相应的论述，在应用反思部分将有深入的讨论。 　　对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。 　　应用反思 　　站在银行窗口焦急等待的用户，在长长的队伍面前显得无奈。所以，将这种无奈迁怒到银行的头上是理所当然的，因为银行业务的管理显然有不当之处。银行的业务人员面对蜂拥而至的客户需求，在排队等待的人们并非只有一种需求，有人存款、有人转账，也有人申购基金，繁忙的业务员来回在不同的需求中穿梭，手忙脚乱的寻找各种处理单据，电脑系统的功能模块也在不同的需求要求下来回切换，这就是一个发生在银行窗口内外的无奈场景。而我每次面对统一排队的叫号系统时，都为前面长长的等待人群而叫苦，从梳理银行业务员的职责来看，在管理上他们负责的业务过于繁多，将其对应为软件设计来实现，你可以将这种拙劣的设计表示如图1所示。 　　按照上述设计的思路，银行业务员要处理的工作，是以这种方式被实现的： 　　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所示。 　　图2 面向抽象的设计 　　按照上述设计实现，用细节表示为： 　　interface IBankProcess 　　{ 　　void Process(); 　　} 　　然后在隔离的接口上，对功能进行扩展，例如改造单一职责的示例将有如下的实现： 　　// 按银行按业务进行分类 　　class DepositProcess : IBankProcess 　　{ 　　//IBankProcess Members 　　#region IBankProcess Members 　　public void Process() 　　{ 　　// 办理存款业务 　　throw new Exception("The method or operation is not implemented."); 　　} 　　#endregion 　　} 　　class TransferProcess : IBankProcess 　　{ 　　//IBankProcess Members 　　#region IBankProcess Members 　　public void Process() 　　{ 　　// 办理转账业务 　　throw new Exception("The method or operation is not implemented."); 　　} 　　#endregion 　　} 　　class DrawMoneyProcess : IBankProcess 　　{ 　　//IBankProcess Members 　　#region IBankProcess Members 　　public void Process() 　　{ 　　// 办理取款业务 　　throw new Exception("The method or operation is not implemented."); 　　} 　　#endregion 　　} 　　这种思路的转换，会让复杂的问题变得简单明了，使系统各负其责，人人实惠。有了上述的重构，银行工作人员彻底变成一个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接口，系统的其他部分将丝毫不受影响，办理新业务的客户会很容易找到受理新增业务的窗口，如图5所示。 　　图5符合OCP的设计 　　对应的实现为： 　　class FundProcess : IBankProcess 　　{ 　　//IBankProcess Members 　　#region IBankProcess Members 　　public void Process() 　　{ 　　// 办理基金业务 　　throw new Exception("The method or operation is not implemented."); 　　} 　　#endregion 　　} 　　可见，新的设计遵守了开放封闭原则，在需求增加时只需要向系统中加入新的功能实现类，而原有的一切保持封闭不变的状态，这就是基于抽象机制而实现的开放封闭式设计。 　　然而，细心观察上述实现你会发现一个非常致命的问题：人们是如何找到其想要处理的业务窗口，难道银行还得需要一部分人力来进行疏导？然而确实如此，至少当前的设计必须如此，所以上述实现并非真正的业务处理面貌，实际上当前“轻松”的银行业务员，还并非真正的“轻松”，我们忽略了这个业务系统中最重要的一部分，就是用户。当前，用户的定义被实现为： 　　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的坏味道依然让每个人看起来都倒胃口，银行业务还是以牺牲客户的选择为代价，难道不能提供一个自发组织客户寻找业务窗口的机制吗？ 　　其中的设计原则就是用于解决上述问题的。 　　规则建议 　　l 开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。 　　l 可以通过Template Method模式和Strategy模式进行重构，实现对修改封闭、对扩展开放的设计思路。 　　l 封装变化，是实现开放封闭原则的重要手段，对于经常发生变化的状态一般将其封装为一个抽象，例如银行业务中的IBankProcess接口。 　　l 拒绝滥用抽象，只将经常变化的部分

开放-封闭”原则是我们OOD的目标，达到这一目标的主要机制就是“依赖倒转”原则(DIP)这个原则的内容是：要依赖于抽象,不要依赖于具体。或者说是：要针对接口编程，不要对实现编程(Program to an interface, not an implementation)。
     对于抽象层次来说，它是一个系统的本质的概括是系统的商务逻辑和宏观的，战略性的决定，是必然性的体现；具体的层次则是与实现有关的算法和逻辑，一些战术性的决定，带有相当大的偶然性。传统的过程性系统设计办法倾向于使高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。这实际上就是微观决定宏观，战术决定战略，偶然决定必然。依赖倒转原则就是要把这种错误的依赖关系倒转过来。
     许多的建构设计模型，例如COM，CORBA，JavaBean，EJB等，它们背后的基本原则就是DIP。
     对于软件设计的两个目标，复用和可维护性来说，传统的设计侧重于具体层次模块的复用和可维护，比如算法，数据结构，函数库等等。但是对系统的抽象是比较稳定的，它的复用是很重要的，同时，抽象层次的可维护性也应当是一个重点。就是说DIP也导致复用和可维护性的“倒转”
     我们现在来看看依赖有几种，依赖也就是耦合,分为下面三种：
     ----- 零耦合(Nil Coupling)关系，两个类没有依赖关系，那就是零耦合。
     ----- 具体耦合(Concrete Coupling)关系，两个具体的类之间有依赖关系，那么就是具体耦合关系，如果一个具体类直接引用另外一个具体类就会发生这种关系。
     -----抽象耦合(Abstract Coupling)关系，这种关系发生在一个具体类和一个抽象类之间，这样就使必须发生关系的类之间保持最大的灵活性。
     DIP要求客户端依赖于抽象耦合，抽象不应当依赖于细节，细节应当依赖于抽象(Abstractions should not depend upon details. Details should depend upon abstractions)，这个原则的另外一个表述就是"四人团"强调的那个：要针对接口编程，不要对实现编程(Program to an interface, not an implementation)，程序在需要引用一个对象时，应当尽可能的使用抽象类型作为变量的静态类型，这就是针对接口编程的含义。DIP是达到"开-闭"原则的途径。
     要做到DIP，用抽象方式耦合是关键。由于一个抽象耦合总要涉及具体类从抽象类继承。并且需要保证在任何引用到某类的地方都可以改换成其子类，因此，LSP是DIP的基础。DIP是OOD的核心原则，设计模式的研究和应用都是用它作为指导原则的。DIP虽然强大，但是也很难实现。另外DIP是假定所有的具体类都会变化，这也不是全对，有些具体类就相当稳定。使用这个类的客户端就完全可以依赖这个具体类而不用再弄一个抽象类。 (引用到此结束)
     对于接口以及接口的作用，让我们用一个类比来理解，这样会更加的直观，我们平时用的插座就可以看做一种接口，我们只通过它就可以用电了，假若供电方式发生了变化，比如由现在的火力发电变为太阳能发电，整个供电线路要进行全面的改修，那麽我们的用电方式并不会受到影响还是通过插座来用电，供电方式发生的变化和线路的改变对我们来说是透明的，这样作的好处通过对比一下下面的情形就可以知道了，假若我们没有通过插座来用电，而是直接与供电站直接通过电线连接，除去安全性的问题不说，若供电方式发生了变化，线路要进行改修，那麽可能就会有人敲你家的门说：“你好，我们是来改装电线的”，而且可能是在凌晨2:00，为什么？城市的每一户人家都要进行这样的改装啊，电路改装人员的工作量实在是太大了，只能7*24的工作了。所以还是打开门吧，否则只能过着没有电的日子了。所以我们通过插座(接口)带来的好处是不是很明显了呢？它降低用电方和供电方的耦合，为变化的实施带来了便利。
     接口是实现插件化(pluggability)的关键，对象间的连接不必硬绑定(hardwire)到一个具体类的对象上，而是绑定在一个较高层次的抽象之上(接口或者抽象类)因此增加了类的灵活性，可以自由的进行“插拔”。通过接口或抽象类可以降低类之间的耦合，一个对象可以很容易地被(实现了相同接口的)的另一个对象所替换，而不会影响这个对象本身，所以一切的变化完全在此对象不知情的情况下进行。