设计模式之禅-学习笔记 之 第一章:单一职责原则

第一章：单一职责原则(SRP:Single responsibility principle)

别称：  单一功能原则，设计模式六个基本原则之一  定义：  There should never be more than one reason for a class to change.(应该有且仅有一个原因引起类的变更)  解释：  单一职责原则要求一个接口、类或方法只有一个原因引起变化，也就是一个接口、类或方法只有一个职责，它就负责一件事情      问题由来：  之所以会出现单一职责原则就是因为在软件设计时会出现一下类似场景：
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起          好处：  1. 类的复杂性降低，实现什么职责都有清晰明确的好处。    2. 可读性提高，复杂性降低，那当然可读性提高了。    3. 可维护性提高，可读性提高，那淡然更容易维护了 。    4. 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对吸纳相应的实现类有影 响，对其他接口无影响，这对系统的扩展性，维护性都有非常大的帮助。      来，亲，咱们扩展一下：设计模式六个基本原则：  1. 单一职责原则(SRP:Single responsibility principle)    2. 里氏替换原则(LSP:Liskov substitution principle)     3. 依赖倒置原则(DIP:Dependency Inversion Principle)    4. 接口隔离原则(ISP:Interface Segregation Principle)    5. 迪米特法则(LOD:Law of Demeter)    6. 开闭原则(OCP:Open Closed Principle)                                               范例：  

图 1-1是一个用户、机构、角色管理的模块，使用的是RBAC模型(Role-Based Access Control,基于角色的访问控制)， 不过这个接口设计的有问题，用户的属性和行为没有分开，这是一个严重的错误！

应该把用户信息抽取成一个BO(Business Object, 业务对象)，IUserBO负责用户的属性，IUserBO 的职责就是收集和反馈 用户的属性信息；把行为抽取成一个Biz(Business Logic, 业务逻辑)，IUserBiz负责用户的行为，完成用户信息的维护和 变更。按照这个思路对类图进行修正。

C++代码实现：

不过在实际是使用中，我们更倾向于使用两个不同的类或接口，一个是IUserBO，一个是IUserBiz，类图如1-3所示：

C++代码实现：

图2-1是电话管理的模块，Iphone这个接口包含了两个职责:一个是协议管理，一个是数据传送，dial()和hangup() 两个方法实现的是协议管理，分别负责拨号接通和挂机；call()和answer()实现了数据传送(通话)。

C++代码实现：