设计模式（三）之单一职责原则

单一职责原则：

官方给的说法是：就一个类而言，应该仅有一个因其他变化的原因。

说白了就是，一个类只负责一项职责。

最简单也是最难的原则。难处在于对职责进行划分。单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

软件设计真正要做的内容，就是发现职责并把那些职责互相分离。单一职责原则可以使类的复杂度降低，实现什么职责都有清晰明确的定义；类的可读性提高，复杂度降低；可读性提高了，代码就更容易维护；变更（需求是肯定会变）引起的风险（包括测试的难度，以及需要测试的范围）降低。

下边使用手机来举例：这个手机我们需要实现播放音乐和拍照片的功能。

不遵循单一设计模式：

主文件：Progam.cs

using System;
namespace simple
{
    class Program
    {
        static void Main(string[] args)
        {
            Imusic music = new Totol();
            Iphoto photo = new Totol();
  
            music.PutMusic();
            photo.PutPhoto();
  
            Console.ReadLine();
        }
    }
}

接口文件：Iphoto.cs

namespace simple
{
    interface Iphoto
    {
        /// <summary>
        /// 拍照片方法
        /// </summary>
        void PutPhoto();
    }
}

接口文件：Imusic

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

子类文件：Totol.cs用于实现上面两个接口

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
  
namespace simple
{
    public class Totol: Iphoto,Imusic
    {
        public void PutPhoto()
        {
            Console.WriteLine("拍照片");
        }
  
        public void PutMusic()
        {
            Console.WriteLine("放音乐");
        }
    }
}

上边的设计显然不符合单一职责原则，totol类中有两个功能，也就是说，我们调用其中任何一个功能的时候，都会引起这个类的变化。

下边我们使用单一职责原则来实现：说的很高大上，说白了就是将totol类中的两个功能分开。

主文件：Program.cs

using System;
  
namespace simple
{
    class Program
    {
        static void Main(string[] args)
        {
            //Imusic music = new Totol();
            //Iphoto photo = new Totol();
  
            Music music = new Music();
            Photo photo = new Photo();
  
            music.PutMusic();
            photo.PutPhoto();
  
            Console.ReadLine();
        }
    }
}

接口文件Iphoto.cs

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

Imusic.sc

namespace simple
{
    interface Imusic
    {
        /// <summary>
        /// 播放音乐方法
        /// </summary>
        void PutMusic();
    }
}

子类Music.cs

using System;
namespace simple
{
    class Music:Imusic
    {
        public void PutMusic()
        {
            Console.WriteLine("放音乐");
        }
    }
}

子类：Photo.cs

using System;
namespace simple
{
    class Photo:Iphoto
    {
        public void PutPhoto()
        {
            Console.WriteLine("拍照片");
        }
    }
}

以上的代码只是一个比较弱智的小例子。理解大概意思就好。

可以用上边的例子继续举例，我们手机最基础的功能只要拍照和放音乐，现在我需要手机可以拍摄有声Gif动图，并且可以播放，那么再修改上，不遵循单一职责原则的类可能就会出现很多意向不到的问题。但是如果他是两个类的话，可能我们修改起来的复杂程度，需要考虑的限制就没有那么多。这个就是单一职责原则的好处。

但是这篇文章最开始的部分也提到了：这个最难的部分还是职责的分离，往往很多项目的奇葩需求和奇葩逻辑，我们没有办法将其分的清楚。所以这个只能尽量遵守，为后期代码的开发做一个好的铺垫。

因为，需求是会变的。

有好的建议，请在下方输入你的评论。