java单一职责原则
定义：应该有且仅有一个原因引起类的变更,也就是接口或类和职责的关系是一一对应的。
解释：假定我们定义了一个类，他有很多的职能（行为），如果其中一个职能发生变化（你修改了其中一个方法），他是不是会影响其他类或方法的使用？
而如果你将其独立出来，你修改对其他的职能影响会降低到很小。
这样我们就实现了低耦合。
案例：
学习java的时候这样的类一定没有少写，但是在工作中你的经理却不会让你这样写，这又是为什么那？
在实际项目中，会有很多类，一个类承担的职责越多，它被复用的可能性就越小，而我们团队开发的时候代码复用，可读性，简洁性尤为重要。
思考：
还是上面的people，我们假定有一万个人，每一个人都是独特的，在一瞬间他们行为可能是相同的也可能是不同。在这一瞬间有一百万个可能，窝进棉被或面对寒冷.............................
按如此设计你将不用写一百万个类型的人，你只需要将这些人的行为定义出来即可。
总结：
- 难点:职责的划分:
- 在不同情景和生产环境下我们对职责的细化是不同的
- 单一职责原则提出的是一个评价接口是否优良的标准
开发是将问题解决，但是每个人解决问题的方式是不同的，设计原则是将我们的思考方式统一的方式，当然这些经验都是前辈们趟雷过来的，所以我们理解遵守就好了。
深入：
有一个A类，具有一个方法；B类，也有一个方法；C类将A类和B类组合在一起实现了一个功能。请问是否遵守单一职责原则？
属于高内聚。
事物都是相对的，当在一个大的系统中，单一的职责可能有很多的组成。
所以说，需求才是爹。
杀死一个程序员的方法改3次需求就够了。