超前的设计或者过度的设计都不是良好的设计，很多时候我们等到代码在第一次变化的时候可以及时作出反应。

　　1.What:就一个类（接口、结构体、方法等等）而言，应该仅有一个引起它变化的原因。

　　2.Why:软件设计真正要做的许多内容，就是发现职责并把那些职责互相分离。单一职责原则可以使类的复杂度降低，实现什么职责都有清晰明确的定义；类的可读性提高，复杂度降低（复杂度降低肯定可读性提高）；可读性提高了，代码就更容易维护；变更（需求是肯定会变的，程序员都知道）引起的风险（包括测试的难度，以及需要测试的范围）降低。

　　3.How:若一个Employee类拥有两个方法CountMoney()、SaveMoney()，对于Employee类来说拥有两个职责，数钱和存钱两个方法，有的时候会以为关于钱的有关动作都让员工类来处理，貌似只有一个职责，那么我们来看看需求的变化，如果有一天数钱的方式从用手数钱换做用点钞机点，那么需要去修改Employee类；现在又来了一个变化，存钱的方式，以前是直接交给老板，现在老板需要你存入指定的账户。以上需求的变化，两种不同的变化我们都要去修改Employee类，当然可能对于两个简单的方法来说，我们不容易出错，但是因为CountMoney()方法的修改，可能就会引起SaveMoney()类的变化。所以更好的处理办法是将类的职责拆分，只拥有一样职责，这样将来面临变化的时候只需要修改其中的一处，那么测试也控制在一定的范围之内。

单一职责原则