单一职责原则__(设计原则)

什么是单一职责?

There should never be more than one reason for a class to change(一个类改变的原因不应该超过一个)

为什么要用单一职责原则

便于维护,阅读

例1:

public interface UserInfo {

    String getUserEmail(String userId);

    boolean setUserEmail(String userId);

    boolean addUser(UserInfo  userInfo);

    boolean delUser(String userId);
}

存在的问题

1. 以上代码存在的问题,这个接口负责了两种操作,
   1. 属性操作
   2. 行为操作 ,
2. 造成的影响
   1. 无论是用户属性操作修改,还是操作用户的修改都会造成该接口的频繁改动,维护一些属性的操作可能会导致行为操作无法正常运行,修改用户行为也可能会造成用户属性操作出现问题!
   2. 如果划分业务的话这两个操作明显应该不是同一个权限!
   3. 如果命名不规范,可能会让你不知道这个是操作的用户属性,还是对整个用户的操作

例2拆分:

用户管理接口

public interface UserManager {

    boolean addUser(UserInfo userInfo);

    boolean delUser(String userId);

    boolean addRole(String userId, String role);

    boolean delRole(String userId);
}

用户属性修改接口

public interface UserOperation {
    String getUserNmae(String userId);

    String setUserNmae(String userId, String userName);

    String setEmail(String userId, String eamil);

    String getEmail(String userId);
}

优点

1. 可以降低类的复杂度，一个类只负责一项职责，其逻辑肯定要比负责多项职责简单的多；
2. 提高类的可读性，提高系统的可维护性；
3. 变更引起的风险降低，变更是必然的，如果单一职责原则遵守的好，当修改一个功能时，可以显著降低对
4. 其他功能的影响。

存在的问题

1. 类或者方法的增加
2. 如何拆分,根据什么来划分,具体细分的什么粒度,是比较麻烦的一件事!
3. 如果拆分的不合理,会大大增加代码的维护难度
4. 开发周期可能会变长(因为需要考虑合理的划分,原本可能只需要在类上增加一个方法就能解决,现在可能需要多划出一个类)

思考

1. 一个合理的划分大大的提升代码的可维护,可扩展,可阅读
2. 实际开发时,尽可能的使用该原则,但是如果使用该原则会提升太多的复杂性,没必要一定使用!
3. 单一职责不仅仅体现在类与接口上,还可以体现在方法上
4. 单一职责,在某些因素的影响下必定带来职责扩散的反单一职责问题,还是那句话,尽可能使用,没必要一定用!

什么是单一职责原则

1. 如果一个类承担的职责过多，就等于把这些职责耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。
2. 这个原则看起来是最简单和最好理解的，但是实际上是很难完全做到的，难点在于如何区分“职责”。这是个没有标准量化的东西，哪些算职责、到底这个职责有多大的粒度、这个职责如何细化等。因此，在实际开发中，这个原则也是最容易违反的