对于一个产品而言，简单一点，职责单一一点或许会更好一点，就像现在的智能手机一样，各种功能，拍照，录像，看电影，
但是就功能而言，拍照没有相机好，录像没得摄像机好等，这个道理就好比设计模式中的单一职责原理是一样的。
定义：就一个类而言，应该仅有一个引起它变化的原因。通俗的讲就是，一个类之负责一个职能。
问题：类T负责两个不同的职责：职责t1，职责t2，由于t1职责需要发生变化时，修改T类，可能会导致t2发生错误。
解决方案：分别建立两个类T1,T2，使他们分别完成t1,t2的职责，这样在t1的职责发生改变时，就不会影响到t2的职责，这就是单一职责原则
下面举个人吃饭的例子说明
1 static void Main(string[] args) 2 { 3 Peple per = new Peple(); 4 per.Eat("北方人"); 5 per.Eat("南方人"); 6 Console.ReadKey(); 7 } 8 9 public class Peple10 {11 public void Eat(string people)12 {13 Console.WriteLine(people + "吃饭");14 }15 } 运行结果：北方人吃饭
南方人吃饭
但是这时，需求变了，北方人吃面，而南方人吃饭，如果遵循单一职责原则，则将人分为北方人和南方人，代码如下：
1 static void Main(string[] args) 2 { 3 SouthPeple per1 = new SouthPeple(); 4 per1.Eat("南方人"); 5 NorthPeple per2 = new NorthPeple(); 6 per2.Eat("北方人"); 7 Console.ReadKey(); 8 } 9 10 public class SouthPeple11 {12 public void Eat(string people)13 {14 Console.WriteLine(people + "吃饭");15 }16 }17 18 public class NorthPeple19 {20 public void Eat(string people)21 {22 Console.WriteLine(people + "吃面");23 }24 } 这样修改的话，除了要将原来的类分离出来，还要修改客户端的代码，而直接修改类People则花销小很多，代码如下：
1 static void Main(string[] args) 2 { 3 Peple per = new Peple(); 4 per.SouthEat("南方人"); 5 per.NortEat("北方人"); 6 Console.ReadKey(); 7 } 8 9 public class Peple10 {11 public void SouthEat(string people)12 {13 Console.WriteLine(people + "吃饭");14 }15 public void NortEat(string people)16 {17 Console.WriteLine(people + "吃饭");18 }19 } 上面代码在类中新增了一个方法，这样虽然违背了单一职责原则，但在方法级别上却符合单一职责原则，因为他并没有动原来的代码，
我觉得，只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；
而实际应用中的类足够复杂，所以还是要遵循单一职责原则。
优点
- 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
- 提高类的可读性，提高系统的可维护性；
- 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。
需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。