单一职责原则

单一职责原则Single Responsibility Principle, SRP)中的职责Responsibility)被表述为“变化的原因”reason to change)；SRP被表述为“一个类应该有且只有一个变化的原因”。
动机：对于设计原则的理解应该首先从它的动机入手，即遵循这个原则带来的好处是什么？对于SRP来讲，如果遵循“一个类应该有且只有一个变化的原因”是因，那么“任何一个变化只会影响一个类”就是果。可见SRP的动机主要是系统的可维护性，即降低适应变化的成本。牵一发而动全身，这显然是我们所不愿意看到的，所以我们会把这个类分拆开来，由两个类来分别维护这两个职责，这样当一个职责发生改变，需要修改时，不会影响到另一个职责。

代码示例

       public interface IUserInfo {
            void getId);
            void getName);
            void addUserint id,String name);
        }

这个接口将业务对象和业务逻辑的内容放到了一个勒种，业务对象和业务逻辑都会引起UserInfo 类的变化，违反了单一职责。
下面我们按照单一职责的要求拆分一下这个接口：

        public interface IUserInfoA {
            void getId);
            void getName);
         }
        public interface IUserInfoB {
              void addUserint id,String name);
         }

将原接口拆分为 A 和 B 两个接口，在需要相应的得操作时去操作相应的接口就实现了我们所说的单一职责，也就是让引起他们变化原因只有一种,并且让相关性强的内容聚合在一个类内部。

拆分前：

拆分后：

优点

降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。
提高了代码的可读性。一个类简单了，可读性自然就提高了。
提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。
变更引起的风险变低了。单一职责最大的优点就是修改一个功能，对其他功能的影响显著降低。

单一职责原则