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

定   义：不要存在多于一个致使类变动的缘由。通俗的说，即一个类只负责一项职责。

问题由来：类T负责两个不一样的职责：职责P1，职责P2。当因为职责P1需求发生改变而须要修改类T时，有可能会致使本来运行正常的职责P2功能发生故障。

解决方案：遵循单一职责原则。分别创建两个类T一、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

   说到单一职责原则，不少人都会不屑一顾。由于它太简单了。稍有经验的程序员即便历来没有读过设计模式、历来没有据说过单一职责原则，在设计软件时也会自觉的遵照这一重要原则，由于这是常识。在软件编程中，谁也不但愿由于修改了一个功能致使其余的功能发生故障。而避免出现这一问题的方法即是遵循单一职责原则。虽然单一职责原则如此简单，而且被认为是常识，可是即使是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。为何会出现这种现象呢？由于有职责扩散。所谓职责扩散，就是由于某种缘由，职责P被分化为粒度更细的职责P1和P2。

好比：类T只负责一个职责P，这样设计是符合单一职责原则的。后来因为某种缘由，也许是需求变动了，也许是程序的设计者境界提升了，须要将职责P细分为粒度更细的职责P1，P2，这时若是要使程序遵循单一职责原则，须要将类T也分解为两个类T1和T2，分别负责P一、P2两个职责。可是在程序已经写好的状况下，这样作简直太费时间了。因此，简单的修改类T，用它来负责两个职责是一个比较不错的选择，虽然这样作有悖于单一职责原则。（这样作的风险在于职责扩散的不肯定性，由于咱们不会想到这个职责P，在将来可能会扩散为P1，P2，P3，P4……Pn。因此记住，在职责扩散到咱们没法控制的程度以前，马上对代码进行重构。）

举例说明，用一个类描述动物呼吸这个场景：

        class Animal{

        public void breathe(String animal){

        System.out.println(animal+"呼吸空气");

        }

        }

        public class Client{

        public static void main(String[] args){

        Animal animal = new Animal();

        animal.breathe("牛");

        animal.breathe("羊");

        animal.breathe("猪");

        }

        }

运行结果：

牛呼吸空气

羊呼吸空气

猪呼吸空气

程序上线后，发现问题了，并非全部的动物都呼吸空气的，好比鱼就是呼吸水的。修改时若是遵循单一职责原则，须要将Animal类细分为陆生动物类Terrestrial，水生动物Aquatic，代码以下：

class Terrestrial{

        public void breathe(String animal){

        System.out.println(animal+"呼吸空气");

        }

        }

        class Aquatic{

        public void breathe(String animal){

        System.out.println(animal+"呼吸水");

        }

        }

        

        public class Client{

        public static void main(String[] args){

        Terrestrial terrestrial = new Terrestrial();

        terrestrial.breathe("牛");

        terrestrial.breathe("羊");

        terrestrial.breathe("猪");

        

        Aquatic aquatic = new Aquatic();

        aquatic.breathe("鱼");

        }

        }

运行结果：

牛呼吸空气

羊呼吸空气

猪呼吸空气

鱼呼吸水

咱们会发现若是这样修改花销是很大的，除了将原来的类分解以外，还须要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代码以下：

class Animal{

        public void breathe(String animal){

        if("鱼".equals(animal)){

        System.out.println(animal+"呼吸水");

        }else{

        System.out.println(animal+"呼吸空气");

        }

        }

        }

        public class Client{

        public static void main(String[] args){

        Animal animal = new Animal();

        animal.breathe("牛");

        animal.breathe("羊");

        animal.breathe("猪");

        animal.breathe("鱼");

        }

        } 

能够看到，这种修改方式要简单的多。可是却存在着隐患：有一天须要将鱼分为呼吸淡水的鱼和呼吸海水的鱼，则又须要修改Animal类的breathe方法，而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险，也许某一天你会发现程序运行的结果变为“牛呼吸水”了。这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但隐患倒是最大的。还有一种修改方式：

        class Animal{

        public void breathe(String animal){

        System.out.println(animal+"呼吸空气");

        }

        

        public void breathe2(String animal){

        System.out.println(animal+"呼吸水");

        }

        }

        public class Client{

        public static void main(String[] args){

        Animal animal = new Animal();

        animal.breathe("牛");

        animal.breathe("羊");

        animal.breathe("猪");

        animal.breathe2("鱼");

        }

        } 

能够看到，这种修改方式没有改动原来的方法，而是在类中新加了一个方法，这样虽然也违背了单一职责原则，但在方法级别上倒是符合单一职责原则的，由于它并无动原来方法的代码。这三种方式各有优缺点，那么在实际编程中，采用哪一中呢？其实这真的比较难说，须要根据实际状况来肯定。个人原则是：只有逻辑足够简单，才能够在代码级别上违反单一职责原则；只有类中方法数量足够少，才能够在方法级别上违反单一职责原则；

例如本文所举的这个例子，它太简单了，它只有一个方法，因此，不管是在代码级别上违反单一职责原则，仍是在方法级别上违反，都不会形成太大的影响。实际应用中的类都要复杂的多，一旦发生职责扩散而须要修改类时，除非这个类自己很是简单，不然仍是遵循单一职责原则的好。

遵循单一职责原的优势有：

• 能够下降类的复杂度，一个类只负责一项职责，其逻辑确定要比负责多项职责简单的多；

• 提升类的可读性，提升系统的可维护性；

• 变动引发的风险下降，变动是必然的，若是单一职责原则遵照的好，当修改一个功能时，能够显著下降对其余功能的影响。

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