设计模式六大原则：单一职责原则

目录： 

　　设计模式六大原则：单一职责原则

　　设计模式六大原则：接口隔离原则 

　　设计模式六大原则：依赖倒置原则

　　设计模式六大原则：里氏替换原则

　　设计模式六大原则：迪米特法则

　　设计模式六大原则：开闭原则

单一职责原则：

　　对象不应承担太多功能，正如一心不能而用，比如太多的工作(种类)会使人崩溃。唯有专注才能保证对象的高内聚；唯有唯一，才能保证对象的细粒度。

解决问题：

　　假如有A和B两个类，当A需求发生改变需要修改时，不能导致B类出问题。

现状：

　　在实际情况很难去做到单一职责原则，因为随着业务的不断变更，类的职责也在发生着变化，即职责扩散。如类A完成职责P的功能，但是随着后期业务细化，职责P分解成更小粒度的P1与P2，这时根据单一职责原则则需要拆分类A以分别满足细分后的职责P1和P2。但是实际开发环节，若类的逻辑足够简单，可以在代码上级别上违背单一职责原则；若类的方法足够少，可以在方法级别上违背单一职责原则。

经典案例：

　　用一个类描述动物呼吸的场景

namespace MyDemo
{
    internal class Animal
    {
        public void breath(string animal)
        {
            Console.WriteLine($"{animal}呼吸空气");
        }
    }
}

namespace MyDemo
{
    internal class Program
    {
        private static void Main(string[] args)
        {
            Animal animal = new Animal();
            animal.breath("🐂");
            animal.breath("🐖");
            animal.breath("🐎");
            animal.breath("🐟");
        }
    }
}

　　从示例可以发现，Animal类已不足以支持客户端所需职责，因为🐟吃水。若遵循单一职责原则，则需要拆分Animal类。 

internal class Terrestrial
    {
        public void breath(string animal)
        {
            Console.WriteLine($"{animal}呼吸空气");
        }
    }

    internal class Aquatic
    {
        public void breath(string animal)
        {
            Console.WriteLine($"{animal}吃水");
        }
    }

 

internal class Program
    {
        private static void Main(string[] args)
        {
            Terrestrial terrestrial = new Terrestrial();
            terrestrial.breath("🐂");
            terrestrial.breath("🐖");
            terrestrial.breath("🐎");

            Aquatic aquatic = new Aquatic();
            aquatic.breath("🐟");
        }
    }

　　这时你会发现，若针对简单的业务逻辑来说，若每次细分都需要拆分的话实在是太繁琐了，而且服务端与客户端代码都需要做相应的修改。所以直接在原先类中进行修改，虽然违背了单一职责原则，但花销小。

internal class Animal
    {
        public void breath(string animal)
        {
            if ("🐟".Equals(animal))
            {
                Console.WriteLine($"{animal}吃水");
            }
            else
            {
                Console.WriteLine($"{animal}呼吸空气");
            }
        }
    }

优点：

　　1、降低类的功能复杂度

　　2、提高系统的可维护性

　　3、变更风险低

参考：https://blog.csdn.net/zhengzhb/article/details/7278174