1 简介

• 定义
  不要存在多于一个导致类变更的原因。
  
• 特点
  一个类/接口/方法只负责一项职责。
  
• 优点
  降低类的复杂度、提高类的可读性，提高系统的可维护性、降低变更引起的风险。
  
• 名字容易让人望文生义，大部分人可能理解成：一个类只干一件事，看起来似乎很合理呀。几乎所有程序员都知道“高内聚、低耦合”，应该把相关代码放一起。

若随便拿个模块去问作者，这个模块是不是只做了一件事，他们异口同声：对，只做了一件事。看来，这个原则很通用啊，所有人都懂，为啥还要有这样一个设计原则？

因为一开始的理解就是错的！错在把单一职责理解成有关如何组合的原则，实际上，它是关于如何分解的。

Robert Martin对单一职责的定义的变化：

《敏捷软件开发：原则、实践与模式》

一个模块应该有且仅有一个变化的原因

《架构整洁之道》

一个模块应该对一类且仅对一类行为者（actor）负责

单一职责原则 V.S 一个类只干一件事

最大的差别就是，将变化纳入考量。

分析第一个定义：一个模块应该有且仅有一个变化的原因。

软件设计关注长期变化，拥抱变化，我们最不愿意面对却不得不面对，只因变化会产生不确定性，可能：

新业务的稳定问题

旧业务遭到损害而带来的问题

所以，一个模块最理想的状态是不改变，其次是少改变，它可成为一个模块设计好坏的衡量标准。

但实际开发中，一个模块频繁变化，在于能诱导它改变的原因太多！

2 案例

2.1 鸟类案例

• 最开始的 Bird 类
• 
• 简单测试类
• 
• 显然鸵鸟还用翅膀飞是错误的！于是，我们修改类实现
• 
• 这种设计依旧很low，总不能一味堆砌 if/else 添加鸟类。结合该业务逻辑，考虑分别实现类职责，即根据单一原则创建两种鸟类即可：
• 
• 

2.2 课程案例

• 最初的课程接口有两个职责，耦合过大
• 
• 按职责拆分
• 
•