设计原则
1 单一职责原则
2 里氏替换原则
3 依赖倒置原则
4 接口隔离原则
5 迪米特法则
6 开闭原则单一职责原则
应该有且仅有一个原因引起类的变更。
我相信， 即使是一个初级的程序员也可以看出这个接口设计得有问题， 用户的属性和用户的行为没有分开， 这是一个严重的错误！ 应该把用户的信息抽取成一个BO（Business Object， 业务对象） ， 把行为抽取成一个Biz（Business Logic， 业务逻辑） ， 按照这个思路对类图进行修正 ：
代码使用:
IUserInfo userInfo = new UserInfo();
//我要赋值了， 我就认为它是一个纯粹的BO
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
//我要执行动作了， 我就认为是一个业务逻辑类
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser(); 确实可以如此， 问题也解决了， 但是我们来分析一下刚才的动作， 为什么要把一个接口拆分成两个呢？ 其实， 在实际的使用中， 我们更倾向于使用两个不同的类或接口： 一个是IUserBO， 一个是IUserBiz ，如下图所示：
以上我们把一个接口拆分成两个接口的动作， 就是依赖了单一职责原则， 那什么是单一职责原则呢？ 单一职责原则的定义是： 应该有且仅有一个原因引起类的变更。
对于接口， 我们在设计的时候一定要做到单一， 但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增， 给维护带来非常多的麻烦， 而且过分细分类的职责也会人为地增加系统的复杂性。 本来一个类可以实现的行为硬要拆成两个类， 然后再使用聚合或组合的方式耦合在一起， 人为制造了系统的复杂性。 所以原则是死的， 人是活的， 这句话很有道理。
单一职责适用于接口、 类， 同时也适用于方法 !
所以， 如果对接口、 类、 方法使用了单一职责原则， 那么快乐的就不仅仅是你了， 还有你的项目组成员， 大家可以轻松而又愉快地进行开发； 还有你的老板， 减少了因为变更引起的工作量， 减少了无谓的人员和资金消耗。 当然， 最快乐的也许就是你了， 因为加官晋爵可能等着你哟！
对于单一职责原则， 建议是接口一定要做到单一职责， 类的设计尽量做到只有一个原因引起变化。
单一职责原则有什么好处：
● 类的复杂性降低， 实现什么职责都有清晰明确的定义；
● 可读性提高， 复杂性降低， 那当然可读性提高了；
● 可维护性提高， 可读性提高， 那当然更容易维护了；
● 变更引起的风险降低， 变更是必不可少的， 如果接口的单一职责做得好， 一个接口修
改只对相应的实现类有影响， 对其他的接口无影响， 这对系统的扩展性、 维护性都有非常大
的帮助