设计模式——单一职责原则

　　对于一个产品而言，简单一点，职责单一一点或许会更好一点，就像现在的智能手机一样，各种功能，拍照，录像，看电影，

但是就功能而言，拍照没有相机好，录像没得摄像机好等，这个道理就好比设计模式中的单一职责原理是一样的。

　　定义：就一个类而言，应该仅有一个引起它变化的原因。通俗的讲就是，一个类之负责一个职能。

　　问题：类T负责两个不同的职责：职责t1，职责t2，由于t1职责需要发生变化时，修改T类，可能会导致t2发生错误。

　　解决方案：分别建立两个类T1,T2，使他们分别完成t1,t2的职责，这样在t1的职责发生改变时，就不会影响到t2的职责，这就是单一职责原则

　　

　　下面举个人吃饭的例子说明

　　

        static void Main(string[] args)
        {
            Peple per = new Peple();
            per.Eat("北方人");
            per.Eat("南方人");
            Console.ReadKey();
        }

        public class Peple
        {
            public void Eat(string people)
            {
                Console.WriteLine(people + "吃饭");
            }
        }    

　　运行结果：北方人吃饭

　　　　　　    南方人吃饭

　　但是这时，需求变了，北方人吃面，而南方人吃饭，如果遵循单一职责原则，则将人分为北方人和南方人，代码如下：

　　　　 static void Main(string[] args)
        {
            SouthPeple per1 = new SouthPeple();
            per1.Eat("南方人");
            NorthPeple per2 = new NorthPeple();
            per2.Eat("北方人");
            Console.ReadKey();
        }

        public class SouthPeple
        {
            public void Eat(string people)
            {
                Console.WriteLine(people + "吃饭");
            }
        }

        public class NorthPeple
        {
            public void Eat(string people)
            {
                Console.WriteLine(people + "吃面");
            }
        }

　　这样修改的话，除了要将原来的类分离出来，还要修改客户端的代码，而直接修改类People则花销小很多，代码如下：

         static void Main(string[] args)
        {
            Peple per = new Peple();
            per.SouthEat("南方人");
            per.NortEat("北方人");
            Console.ReadKey();
        }

        public class Peple
        {
            public void SouthEat(string people)
            {
                Console.WriteLine(people + "吃饭");
            }
            public void NortEat(string people)
            {
                Console.WriteLine(people + "吃饭");
            }
        } 

　　上面代码在类中新增了一个方法，这样虽然违背了单一职责原则，但在方法级别上却符合单一职责原则，因为他并没有动原来的代码，

我觉得，只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则；

而实际应用中的类足够复杂，所以还是要遵循单一职责原则。

　　优点

• 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
• 提高类的可读性，提高系统的可维护性；
• 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对其他功能的影响。

        需要说明的一点是单一职责原则不只是面向对象编程思想所特有的，只要是模块化的程序设计，都适用单一职责原则。