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

这里想吐槽一下，可能由于最近优快云升级，导致我辛辛苦苦写了两天的记录丢失了（退出前确定按了保存的），真是够了！！！现在权当再复习一遍！

好了，废话不多说，开始整理Java设计原则！

六大设计原则

• Java设计原则 - 单一职责原则
• Java设计原则 - 里氏替换原则
• Java设计原则 - 依赖倒置原则
• Java设计原则 - 接口隔离原则
• Java设计原则 - 迪米特法则
• Java设计原则 - 开闭原则

定义

应该有且仅有一个原因引起类的变更。通俗的说，即一个类只负责一项职责。

虽然很容易理解，不就是一个类只负责一项职责吗，但是却很难做到，因为很难划分职责。

我们来一个场景说明一下单一职责原则的好处。

场景

现需求设计一个工程师类，要求工程师类具有在电脑上编写代码的能力

public class Engineer {
    public void code(Computer computer) {
        System.out.println("工程师正使用" + computer.getName() + "敲代码");
    }
}

后来增加一个需求，要求工程师类还有测试手机软件的能力

public class Engineer {
    public void code(Computer computer) {
        System.out.println("工程师正使用" + computer.getName() + "敲代码");
    }
    public void test(Phone phone) {
        System.out.println("工程师在" + phone.getName() + "上测试软件");
    }
}

再后来又增加一个需求，要求工程师类还有统计报表的能力

public class Engineer {
    public void code(Computer computer) {
        System.out.println("工程师正使用" + computer.getName() + "敲代码");
    }
    public void test(Phone phone) {
        System.out.println("工程师在" + phone.getName() + "上测试软件");
    }
    public void statistics(ReportForm reportForm) {
        System.out.println("工程师在" + reportForm.getName() + "统计数据");
    } 
}

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

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

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

public class CodeEngineer {
    public void code(Computer computer) {
        System.out.println("工程师正使用" + computer.getName() + "敲代码");
    }
}
public class TestEngineer {
    public void test(Phone phone) {
        System.out.println("工程师在" + phone.getName() + "上测试软件");
    }
}
public class StatisticsEngineer {
    public void statistics(ReportForm reportForm) {
        System.out.println("工程师在" + reportForm.getName() + "统计数据");
    } 
}

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

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

优点

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

难点

• 在于怎么合理划分职责

划分粒度太大，达不到单一职责效果；划分粒度太细，会导致类膨胀，也会产生没必要的花销。

至于怎么划分职责，还得靠自己的开发经验，年轻人，慢慢积累吧，路还远着呢！！