单一职责原则：
官方给的说法是：就一个类而言，应该仅有一个因其他变化的原因。
说白了就是，一个类只负责一项职责。
最简单也是最难的原则。难处在于对职责进行划分。单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。
软件设计真正要做的内容，就是发现职责并把那些职责互相分离。单一职责原则可以使类的复杂度降低，实现什么职责都有清晰明确的定义；类的可读性提高，复杂度降低；可读性提高了，代码就更容易维护；变更（需求是肯定会变）引起的风险（包括测试的难度，以及需要测试的范围）降低。
下边使用手机来举例：这个手机我们需要实现播放音乐和拍照片的功能。
不遵循单一设计模式：
主文件：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动图，并且可以播放，那么再修改上，不遵循单一职责原则的类可能就会出现很多意向不到的问题。但是如果他是两个类的话，可能我们修改起来的复杂程度，需要考虑的限制就没有那么多。这个就是单一职责原则的好处。
但是这篇文章最开始的部分也提到了：这个最难的部分还是职责的分离，往往很多项目的奇葩需求和奇葩逻辑，我们没有办法将其分的清楚。所以这个只能尽量遵守，为后期代码的开发做一个好的铺垫。
因为，需求是会变的。
有好的建议，请在下方输入你的评论。
网友评论