设计模式之七大设计原则《单一职责原则》

本文主要是介绍设计模式之七大设计原则《单一职责原则》，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1、设计模式的重要性

1) 软件工程中，设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方

案。这个术语是由埃里希·伽玛（Erich Gamma）等人在 1990 年代从建筑设计领域引入到计算机科学的

2) 大厦 VS 简易房

3) 拿实际工作经历来说, 当一个项目开发完后，如果客户提出增新功能，怎么办?。（可扩展性,使用设计模式，软

件具有很好的扩展性）

4) 如果项目开发完后，原来程序员离职，你接手维护该项目怎么办? (维护性[可读性、规范性])

5) 目前程序员门槛越来越高，一线 IT 公司(大厂)，都会问你在实际项目中使用过什么设计模式，怎样使用的，解

决了什么问题。

6) 设计模式在软件中哪里？面向对象(oo)=>功能模块[设计模式+算法(数据结构)]=>框架[使用到多种设计模式]=>

架构 [服务器集群]

7) 如果想成为合格软件工程师，那就花时间来研究下设计模式是非常必要的.

2、设计模式的目的

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的
挑战，设计模式是为了让程序(软件)，具有更好
1) 代码重用性 (即：相同功能的代码，不用多次编写)
2) 可读性 (即：编程规范性, 便于其他程序员的阅读和理解)
3) 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护)
4) 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响)
5) 使程序呈现高内聚，低耦合的特性
分享金句：
6) 设计模式包含了面向对象的精髓，“懂了设计模式，你就懂了面向对象分析和设计（OOA/D）的精要”
7) Scott Mayers 在其巨著《Effective C++》就曾经说过：C++老手和 C++新手的区别就是前者手背上有很多伤疤

3、设计模式七大原则

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础(即：设计模式为什么
这样设计的依据)
 设计模式常用的七大原则有:
1) 单一职责原则
2) 接口隔离原则
3) 依赖倒转(倒置)原则
4) 里氏替换原则
5) 开闭原则
6) 迪米特法则
7) 合成复用原则

开始从单一职责原则讲起：

4、单一职责原则

单一职责原则的英文名称是Single Responsibility Principle，简称是SRP。这个设计原则备受争议，只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。如果你是老大，看到一个接口或类是这样或那样设计的，你就问一句：“你设计的类符合SRP原则吗？”保准对方立马“萎缩”掉，而且还一脸崇拜地看着你，心想：“老大确实英明”。这个原则存在争议之处在哪里呢？就是对职责的定义，什么是类的职责，以及怎么划分类的职责。我们先举个例子来说明什么是单一职责原则。

只要做过项目，肯定要接触到用户、机构、角色管理这些模块，基本上使用的都是RBAC模型（Role-Based Access Control，基于角色的访问控制，通过分配和取消角色来完成用户权限的授予和取消，使动作主体（用户）与资源的行为（权限）分离），确实是一个很好的解决办法。我们这里要讲的是用户管理、修改用户的信息、增加机构（一个人属于多个机构）、增加角色等，用户有这么多的信息和行为要维护，我们就把这些写到一个接口中，都是用户管理类嘛，我们先来看它的类图，如图1-1所示。

太Easy的类图了，我相信，即使是一个初级的程序员也可以看出这个接口设计得有问题，用户的属性和用户的行为没有分开，这是一个严重的错误！这个接口确实设计得一团糟，应该把用户的信息抽取成一个BO（Bussiness Object，业务对象），把行为抽取成一个Biz（Business Logic，业务逻辑），按照这个思路对类图进行修正，如图1-2所示。

重新拆封成两个接口，IUserBO负责用户的属性，简单地说，IUserBO的职责就是收集和反馈用户的属性信息；IUserBiz负责用户的行为，完成用户信息的维护和变更。各位可能要说了，这个与我实际工作中用到的User类还是有差别的呀！别着急，我们先来看一看分拆成两个接口怎么使用。OK，我们现在是面向接口编程，所以产生了这个UserInfo对象之后，当然可以把它当IUserBO接口使用。也可以当IUserBiz接口使用，这要看你在什么地方使用了。要获得用户信息，就当是IUserBO的实现类；要是希望维护用户的信息，就把它当作IUserBiz的实现类就成了，如代码清单1-1所示。

……
IUserBiz userInfo=new UserInfo（）；
//我要赋值了，我就认为它是一个纯粹的BO
IUserBO userBO=（IUserBO）userInfo；
userBO.setPassword（"abc"）；
//我要执行动作了，我就认为是一个业务逻辑类
IUserBiz userBiz=（IUserBiz）userInfo；
userBiz.deleteUser（）；
……

基本介绍

对类来说的，即一个类应该只负责一项职责。如类 A 负责两个不同职责：职责 1，职责 2。当职责 1 需求变更
而改变 A 时，可能造成职责 2 执行错误，所以需要将类 A 的粒度分解为 A1，A2

应用实例

1) 方案 1
[分析说明]
package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility1 {
   public static void main(String[] args) {
       Vehicle vehicle = new Vehicle();
       vehicle.run("摩托车");
       vehicle.run("汽车");
       vehicle.run("飞机");
   }
}
// 交通工具类
// 方式 1
// 1. 在方式 1 的 run 方法中，违反了单一职责原则
// 2. 解决的方案非常的简单，根据交通工具运行方法不同，分解成不同类即可
class Vehicle {
   public void run(String vehicle) {
       System.out.println(vehicle + " 在公路上运行....");
   }
}

2) 方案 2

[分析说明]
package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility2 {
   public static void main(String[] args) {
       RoadVehicle roadVehicle = new RoadVehicle();
       roadVehicle.run("摩托车");
       roadVehicle.run("汽车");
       AirVehicle airVehicle = new AirVehicle();
       airVehicle.run("飞机");
   }
}
//方案 2 的分析
//1. 遵守单一职责原则
//2. 但是这样做的改动很大，即将类分解，同时修改客户端
//3. 改进：直接修改 Vehicle 类，改动的代码会比较少=>方案 3
class RoadVehicle {
   public void run(String vehicle) {
       System.out.println(vehicle + "公路运行");
   }
}
class AirVehicle {
   public void run(String vehicle) {
       System.out.println(vehicle + "天空运行");
   }
}
class WaterVehicle {
   public void run(String vehicle) {
       System.out.println(vehicle + "水中运行");
   }
}

3) 方案 3
[分析说明]
package com.atguigu.principle.singleresponsibility;
public class SingleResponsibility3 {
   public static void main(String[] args) {
       Vehicle2 vehicle2 = new Vehicle2();
       vehicle2.run("汽车");
       vehicle2.runWater("轮船");
       vehicle2.runAir("飞机");
   }
}
//方式 3 的分析
//1. 这种修改方法没有对原来的类做大的修改，只是增加方法
//2. 这里虽然没有在类这个级别上遵守单一职责原则，但是在方法级别上，仍然是遵守单一职责
class Vehicle2 {
   public void run(String vehicle) {
       //处理
       System.out.println(vehicle + " 在公路上运行....");
   }
   public void runAir(String vehicle) {
       System.out.println(vehicle + " 在天空上运行....");
   }
   public void runWater(String vehicle) {
       System.out.println(vehicle + " 在水中行....");
   }
}

单一职责原则注意事项和细节
1) 降低类的复杂度，一个类只负责一项职责。
2) 提高类的可读性，可维护性
3) 降低变更引起的风险
4) 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中
方法数量足够少，可以在方法级别保持单一职责原则【一个方法承担一个职责】

5)通常情况下，如果一个类中的方法特别多的时候，而且每个功能和具体类别有关的话，那么我们需要设计成多个类，不能方法智能单一原则了，需要类单一职责原则

6）变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。看过电话这个例子后，是不是想反思一下了，我以前的设计是不是有点问题了？不，不是的，不要怀疑自己的技术能力，单一职责原则最难划分的就是职责。一个职责一个接口，但问题是“职责”没有一个量化的标准，一个类到底要负责那些职责？这些职责该怎么细化？细化后是否都要有一个接口或类？这些都需要从实际的项目去考虑，从功能上来说，定义一个IPhone接口也没有错，实现了电话的功能，而且设计还很简单，仅仅一个接口一个实现类，实际的项目我想大家都会这么设计。项目要考虑可变因素和不可变因素，以及相关的收益成本比率，因此设计一个IPhone接口也可能是没有错的。但是，如果纯从“学究”理论上分析就有问题了，有两个可以变化的原因放到了一个接口中，这就为以后的变化带来了风险。如果以后模拟电话升级到数字电话，我们提供的接口IPhone是不是要修改了？接口修改对其他的Invoker类是不是有很大影响？
注意单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。