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