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

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

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

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

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

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)

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(几何计算的应用程序)

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(图形绘制的应用程序)

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接口,大多数人会认为这个接口看起来非常正常,的确该接口也定义一个调制解调器所具有的功能.

 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负责进行数据通信.这两个职责应该分开吗?这需要依赖于应用程序变化的方式.假设因为应用程序变化导致负责连接管理的函数签名发生变化,那么这个设计就具有僵化性.因为调用负责数据通信的类必须重新编译和部署.这种情况下这两个职责应该被分离.

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

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

 

结论:

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