OOP的几个原则-----SRP:单一职责原则

单一职责原则的定义是:一个类应该只有一个发生变化的原因.

为什么需要将不同职责分离到单独的类中?每个职责都存在一个变化点,当需求发生变化时,该变化会反映为类的职责变化.如果一个类承担了太多的职责,那么引起它变化的原因就会有多个.同时,一个类承担太多职责,说明这个类具有很强的耦合性,如果依赖的模块越多,当该类发生变化,脆弱性就越严重.

考虑一个示例,有两个应有程序使用Rectangle类,其中一个应用程序是有关计算几何方面的,利用Rectangle类计算几何形状,但不会绘制在屏幕上.另外一个应用程序是关于图形绘制的,它可能也会进行一些几何计算方面的工作,并在屏幕上绘制矩形.下面代码是我的一个实现.

SRP.Bad.GUICommon(提供图形的屏幕定位和显示)

View Code

namespace SRP.Bad.GUICommon
{
     public  class GUI
    {
         private  int pointX;
         private  int pointY;
        
         ///   <summary>
         ///  显示图形
         ///   </summary>
         ///   <param name="Width"></param>
         ///   <param name="Length"></param>
         public  void ShowGraphical( double Width,  double Length)
        {
            Console.WriteLine( " 在点[{0},{1}]处绘制一个长度为:{2},宽度为{3}的矩形 ", pointX, pointY, Length, Width);
        }

         ///   <summary>
         ///  在屏幕上设置绘制图形的起始坐标点
         ///   </summary>
         ///   <param name="x"></param>
         ///   <param name="y"></param>
         public  void SetCoordinates( int x,  int y)
        {
            pointX = x;
            pointY = y;
        }
    }
}

 

SRP.Bad.RectangleCommon(一个矩形类,该处依赖了GUICommon)

View Code

namespace SRP.Bad.RectangleCommon
{
     public  class Rectangle
    {
         public  double Width;
         public  double Length;

         ///   <summary>
         ///  绘制一个图形
         ///   </summary>
         ///   <param name="gui"> GUI不代表具体的类,很有可能只是一个抽象类或者接口 </param>
         public  void Draw(GUICommon.GUI gui)
        {
            gui.ShowGraphical(Width, Length);
        }

         ///   <summary>
         ///  计算面积
         ///   </summary>
         ///   <returns></returns>
         public  double Area()
        {
             return Width * Length;
        }
    }
}

 

SRP.Bad.ComputerApplication(几何计算的应用程序)

View Code

namespace SRP.Bad.ComputerApplication
{
     class Program
    {
         static  void Main( string[] args)
        {
             // 让用户输入矩形长宽
            RectangleCommon.Rectangle r =  new SRP.Bad.RectangleCommon.Rectangle();
            r.Width =  100.00;
            r.Length =  35.89;
            Console.WriteLine( " 该矩形面积为:{0} ", r.Area());
            Console.Read();
        }
    }
}

 

SRP.Bad.GraphicalApplication(图形绘制的应用程序)

View Code

namespace SRP.Bad.GraphicalApplication
{
     class Program
    {
         static  void Main( string[] args)
        {
             // 设置一个矩形的大小
            Bad.RectangleCommon.Rectangle r =  new SRP.Bad.RectangleCommon.Rectangle();
            r.Length =  38.95;
            r.Width =  5.82;
             // 在屏幕上定位一个坐标
            Bad.GUICommon.GUI gui =  new SRP.Bad.GUICommon.GUI();
            gui.SetCoordinates( 20, - 5);
            
             // 绘制矩形
            r.Draw(gui);
            Console.Read();
        }
    }
}

为什么Rectangle.Draw方法需要一个GUI参数?考虑到Rectangle类自身提供绘制图形的方法,以后如果需要更多的图形,就不必在GUI里修改了.

 

示例代码呈现的依赖关系

 为什么会违反单一职责原则?就需求来说,Rectangle类具有两个职责,一个是提供了矩形几何形状计算的模型,一个是把矩形绘制在用户图形界面上.这样会导致

ComputerApplication程序必须包含GUI的代码,使得应用程序和GUI组件一起构建和部署;其次,当GraphicalApplication程序的一些改变迫使Rectangle类进行改变,同样的,ComputerApplication程序必须重新测试,构建和部署.如果忘记这样做,ComputerApplication程序会产生一些意想不到的错误.

一个比较好的设计是将Rectangle类的计算部分移到GeometricRectangle类中,这样绘制矩形方式的改变就不会对ComputerApplication程序产生影响.

 

定义职责:

在单一职责原则中,可以将职责定义为变化的原因.如果你能够想到多于一个的动机去改变一个类,这个类就具有多个职责.通常我们都习惯以组的方式去考虑职责.例如下面这个Modem接口,大多数人会认为这个接口看起来非常正常,的确该接口也定义一个调制解调器所具有的功能.

View Code

  public  interface Modem
    {
         ///   <summary>
         ///  拨号
         ///   </summary>
         ///   <param name="pno"></param>
         void Dial( string pno);
         ///   <summary>
         ///  挂断
         ///   </summary>
         void Hangup();
         ///   <summary>
         ///  发送数据
         ///   </summary>
         ///   <param name="c"></param>
         void Send( char c);
         ///   <summary>
         ///  接受数据
         ///   </summary>
         void Recv();
    }

然而就功能上分类来说,这个接口却定义了两种职责:一种职责负责连接管理,一种职责负责数据收发.dial和hangup负责进行调制解调器的连接处理,send和recv负责进行数据通信.这两个职责应该分开吗?这需要依赖于应用程序变化的方式.假设因为应用程序变化导致负责连接管理的函数签名发生变化,那么这个设计就具有僵化性.因为调用负责数据通信的类必须重新编译和部署.这种情况下这两个职责应该被分离.

另一方面,如果应用程序的变化总是导致这两种职责同时变化,那么就不必分离它们.实际上,分离它们又会产生不必要的复杂性.

此时可以得出一个推论,仅当发生变化时,变化的轴线才具有实际意义,除此而外,应用单一职责原则或者其他原则都是不明智的.

 

结论:

单一职责原则是所有原则中最简单的一种,也是最难应用的一种.通常在程序不发生变化时,我们会自然地爸职责结合在一起.软件设计真正要做的许多事情,就是发现职责并把那些职责互相分离.

转载于:https://www.cnblogs.com/bit64/archive/2012/02/29/2370693.html