设计模式六大原则——单一职责原则

单一职责原则

1.概念

Single Responsibility Principle，SRP：
应该有且仅有一个原因引起类的变更，也就是说，一个类只有一个职责，如果职责过多，代码就会臃肿，可读性更差，也更难以维护。

2.好处

1、提高类的可维护性和可读写性
2、降低变更的风险

3.实践

IUserBO负责收集和反馈用户的属性信息；IUserBiz负责用户的行为，用户信息的维护和变更。

IUserInfo userInfo = new UserInfo();
IUserBO userBO = (IUserBO)userInfo;
userBO.setPassword("abc");
IUserBiz userBiz = (IUserBiz)userInfo;
userBiz.deleteUser();

实际上，我们更倾向于使用两个不同的类或接口；
接下来再看一个例子

因为Phone不止一个职责，它包含协议管理和数据传送，且不互相影响，考虑分成两个接口，如图1-5所示。
但一个手机类把ConnectionManager和DataTransfer组合在一起使用，组合是一种强耦合关系，彼此有共同的生命周期，增加了类的复杂性，所以做了修改。

一个类实现了两个接口，把两个职责融合在一个类中。面向接口编程，对外实现的是接口而不是实现类。

对于接口，我们在设计的时候一定要做到单一，但对于实现类就要多方面考虑。过分细分类的职责会人为地增加系统的复杂性。
单一职责原则适用于接口和类，也适用于方法。一个方法尽可能做一件事情，比如一个方法修改用户密码，不要放在“修改用户信息中”，这个方法的颗粒度很粗，如图1-7所示的方法。

4.与接口隔离区别

单一职责原则和接口隔离原则有一定的关系，接口隔离以后，职责就单一了，实现这个接口的类的职责自然也就单一了。但是接口隔离关注的是抽象层，单一职责关注的是两者兼而有之，偏重于实现。

参考：《设计模式之禅》秦小波