1：什么情况下 会使用到单一职责原则设计模式？
当同一个类中同时出现业务和属性等代码的时候或者当同一个类中要做多样事情的时候，就需要将其抽象出来，做成多种不同的接口，以便后续方便扩展
单一职责：原则要求一个接口或者类只有一个原因引起变化，也就是一个接口或者类只有一个职责，它就负责一件事情
单一原则的好处：
类的复杂性降低，实现责任清晰明确
可读性高，复杂性降低
可维护性提高，可读性提高
变更引起风险性降低，变更是必不可少的，如果接口修改，只影响对应的实现类，对其他接口没有影响
如上图所示：
Perion类这样实现，很合适，如果将其优化，可以拆成2个不同的基类或者不同的接口去实现，
name id age 这属于属性，可以单独拆成一个类，而work play属于动作，可以拆成业务实现，如上旁边的
拆成2个不同的类或者接口，子类继承或者实现该接口，当改变接口，无需改动其他的类，这样影响点，变得很小
在实际应用中，使用单一职责模式，最主要的是区分一个业务的场景中 区分其职责，才能使用很好的使用职责模式，但也不一定要非得遵循单一职责模式进行设计
单一职责适用于接口、类，同时也适用于方法。一个方法尽可能做一件事情。
对于单一职责，接口尽可能的使用单一职责，类的设计尽量做到单一设计模式(设计尽量做到只有一个原因引起变化)
把业务信息抽取成一个业务对象（Business Object, 业务对象），把业务行为也抽取成一个对象（Business Logic，业务逻辑）.