单一职责
单一职责原则
There should never be more than one reason for a class to change.
单一职责原则的定义是就一个类而言，应该仅有一个引起他变化的原因。也就是说一个类应该只负责一件事情。如果一个类负责了方法 M1,方法 M2 两个不同的事情，当 M1 方法发生变化的时候，我们需要修改这个类的 M1 方法，但是这个时候就有可能导致 M2 方法不能工作。这个不是我们期待的，但是由于这种设计却很有可能发生。所以这个时候，我们需要把 M1 方法，M2 方法单独分离成两个类，让每个类只专心处理自己的方法。
要真正理解并正确运用单一职责原则，并没有那么容易。单一职责就跟“盐少许”一样，不好把握。单一职责原则某种程度上说是在分离关注点。分离不同角色的关注点，分离不同时间的关注点。
-
利益相关者角色是一个重要的变化原因，不同的角色会有不同的需求，从而产生不同的变化原因。作为居民，家用的电线是普通的 220V 电线，而对电网建设者，使用的是高压电线。用一个 Wire 类同时服务于两类角色，通常意味着坏味道。
-
变更频率是另一个值得考虑的变化原因。即使对同一类角色，需求变更的频率也会存在差异。最典型的例子是业务处理的需求比较稳定，而业务展示的需求更容易发生变更，毕竟人总是喜新厌旧的。因此这两类需求通常要在不同的类中实现。
单一职责原则可以降低类的复杂度，一个类只负责一项职责，这样逻辑也简单很多。提高类的可读性，和系统的维护性，因为不会有其他奇怪的方法来干扰我们理解这个类的含义 当发生变化的时候，能将变化的影响降到最小，因为只会在这个类中做出修改。