单一职责原则是什么

应该有且仅有一个原因引起变更。通俗的将就是一个接口一个类一个方法干的事情不要杂合在一起。

因为技术经验和技术水平，往往我们写出的代码基本上很少遵循单一的职责原则，具体还是要根据项目。在没有接触到单一职责原则我基本上不会分一个业务对象的属性和行为，这其实很不利于日后的维护和扩展。

单一职责的好处（三高）

可读性高，可维护性高，可扩展性高

例子

没有遵循单一职责的例子

????

public interface IUserInfo {

    boolean setUserInfo(UserInfo userInfo);

    UserInfo getUserInfo();

    boolean changePassword(String password);
}

修改成单一职责，可以将接口拆分成两个接口

Bussiness Logic

public interface IUserInfoBiz {
    boolean changePassword(String password);
}

Bussiness Object

public interface IUserInfoBO {

    boolean setUserInfo(UserInfo userInfo);

    UserInfo getUserInfo();
}

职责单一了，我们的类也变多了，其实还是需要根据项目实际出发。