设计原则之单一职责原则

Java设计原则之单一职责原则

无论是什么设计原则，全部都是围绕“项目的生命周期”和“高内聚，低耦合”这两个关键字。

定义

单一职责原则（SRP：Single responsibility principle）又称单一功能原则，它规定了一个类应该只有一个发生变化的原因，即一个类只负责一项职责。

字面上很好理解，但是如果做起来却很难做到，因为很难划分职责。

代码

现需求设计一个用户类，要求用户类具有操作手机的能力。

public class User {
    public void answer(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "接电话");
    }
}

后来增加了一个需求，要求用户还需要具有打电话的能力。

public class User {
    public void answer(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "接电话");
    }
    
    public void call(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "打电话");
    }
}

再后来，又增加了一个需求，要求用户还需要具有用手机玩游戏的能力。

public class User {
    public void answer(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "接电话");
    }
    
    public void call(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "打电话");
    }
    
    public void play(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "玩游戏");
    }
}

再再后来，又增加一个需求…

说到这，我们来分析一下有什么不妥？虽然前期用户类增加功能看似很简单，但是功能越多，意味着依赖的模块也就越多。当其中某一模块出现问题，整个类也会随之异常。这就是有多个原因导致类变更的情况。

怎么解决？好办，划分职责：

public class AnswerUser {
    public void answer(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "接电话");
    }
}

public class CallUser {
    public void call(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "打电话");
    }
}

public class PlayUser {
    public void play(Phone phone) {
        System.out.println("用户正使用" + phone.getName() + "玩游戏");
    }
}

这样划分之后，每个用户类都只依赖一个模块，其中一个模块出现问题，也只是一个某一个用户类出现问题，其他两个用户类不受之影响。

可能上面的例子比较简单，不足体现出单一职责原则的好处。但实际上，由于一个类功能越多，就越多用户类去使用这个功能强大的类（因为啥都能干呀），一旦这个功能强大的类出现异常，可能就得修改这么多个用户类，导致 “牵一发而动全身” 。而且由于类功能强大，依赖的模块越多，也就越容易出问题。

优点

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

难点

• 怎样合理的划分职责

划分粒度太大，达不到单一职责原则。划分粒度太小，会导致类爆炸，也会产生没必要的花销。

至于怎么划分职责，还需要各位结合实际项目需求以及利用自己的开发经验，去做出最合理的划分。