单一职责原则

面向对象的6大设计原则

1.单一职责原则（single responsibility principle，简称srp）

对于类来说，每个类都有单独的职责，不应该将原本不属于该类的行为放在该类里面，我们可以看下面这个例子：

public interface IUserInfo { 
     void setUserID(String userID);
     String getUserID();
     void setPassword(String password);
     String getPassword();
     void setUserName(String userName);
     String getUserName();
     boolean changePassword(String password);
     boolean deleteUser();
     void mapUser();
     boolean addOrg();
     boolean addRole();
     }
public class UserInfo implements IUserInfo ...

首先我们将方法都放置在一个接口里面，然后用我们需要创建的实例去实现它，这是方便我们对接口编程，虽然这个例子将方法都放在接口里面了，但是这个接口设计得很有问题，用户的属性和行为没有分开。我们可以试着修改下这个接口。

public interface IUserBO { 
     void setUserID(String userID);
     String getUserID();
     void setPassword(String password);
     String getPassword();
     void setUserName(String userName);
     String getUserName();
}
public interface IUserBiz { 
     boolean changePassword(String password);
     boolean deleteUser();
     void mapUser();
     boolean addOrg();
     boolean addRole();
}
public interface IUserInfo implements IUserBiz, IUserBO 
public class UserInfo implements IUserInfo...

像上面这个例子一样，我们将用户的行为和属性拆分成了两个接口，然后让我们的类去实现这两个接口。但是这种方式有一个不合理的地方就是在我们需要调用两个接口中的方法的时候，我们需要将UserInfo进行两次转化。如下所示：

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

这样子的调用显得太过于繁琐，所以我们可以让两个类分别实现两个接口，一个类用于存储用户信息，一个类用于负责用户的行为，这就类似于android里面的mvp框架里面的m和p，p负责逻辑处理，也就是用户的行为。 如下所示：

 public interface IUserBO { 
     void setUserID(String userID);
     String getUserID();
     void setPassword(String password);
     String getPassword();
     void setUserName(String userName);
     String getUserName();
}
public interface IUserBiz { 
     boolean changePassword(String password);
     boolean deleteUser();
     void mapUser();
     boolean addOrg();
     boolean addRole();
}
public class UserAction implements IUserBiz...
public class UserInfo implements IUserBO...

这样，UserAction类实现于用户行为接口，UserInfo类实现于用户信息接口，然后现只需要让这两个类进行交互就行了。上面这个例子仅仅是为了解释一下什么是单一职责原则，因为这个原则很难区分清楚，我们很难去区分一个方法究竟该不该属于一个类。
关于单一职责的定义就是：有且仅有一个原因引起类的变更。这个是我们翻译的，实际上原话的解释是这样的：There should never be more than one reason for a class to change.

单一职责原则有着下面的优点：
1.类的复杂性降低，实现什么职责都有清晰明确的定义；
2.可读性提高，复杂性降低，那当然可读性提高了；
3.可维护性提高，可读性提高，那当然更容易维护了；
4.变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

虽然单一职责能够让每个接口职责分明，结构清晰，但是有时候会增加类的复杂性，因为组合是一种强耦合关系，有着共同的生命周期，所以，单一职责原则仅仅只是提出了一个编写程序的标准，用职责和变化原因来衡量类的接口货类的设计设计是否合理，但是职责和变化原因都是不可估量的，因项目的不同而不同。

对于方法来说，单一职责原则要求了一个方法尽可能的只做一件事情，比如一个方法修改用户密码，而不是修改用户信息。

                                            引用于：设计模式之禅