Java设计原则 - 单一职责原则
2018-03-14 15:51
232 查看
这里想吐槽一下,可能由于最近CSDN升级,导致我辛辛苦苦写了两天的记录丢失了(退出前确定按了保存的),真是够了!!!现在权当再复习一遍!
好了,废话不多说,开始整理Java设计原则!
Java设计原则 - 里氏替换原则
Java设计原则 - 依赖倒置原则
Java设计原则 - 接口隔离原则
Java设计原则 - 迪米特法则
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() + "统计数据"); } }
这样划分之后,每个工程师类都只依赖一个模块,其中一个模块出现问题,也只是一个工程类出现问题,其他两个工程类不受之影响。
可能上面的例子比较简单,不足体现出单一职责原则的好处。但实际上,由于一个类功能越多,就越多客户类去使用这个功能强大的类(因为啥都能干呀),一旦这个功能强大的类出现异常,可能就得修改这么多个客户类,导致 “牵一发而动全身” 。而且由于类功能强大,依赖的模块越多,也就越容易出问题。
优点
可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多;提高类的可读性,提高系统的可维护性;
变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
难点
在于怎么合理划分职责划分粒度太大,达不到单一职责效果;划分粒度太细,会导致类膨胀,也会产生没必要的花销。
至于怎么划分职责,还得靠自己的开发经验,年轻人,慢慢积累吧,路还远着呢!!
相关文章推荐
- java设计原则 第一篇---- 单一职责原则
- Java设计模式学习笔记---单一职责原则(一)
- java 设计模式六大原则(1):单一职责原则
- java设计模式_单一职责原则
- <Java设计模式>---单一职责原则
- Java 设计模式(十) 单一职责原则(SRP)
- Java与设计模式(三)设计原则--单一职责原则
- Java设计模式之单一职责原则(Single Responsibility Principle)
- Java设计模式-21-单一职责原则
- java设计模式之单一职责原则(SRP)
- 简单讲解Java设计模式编程中的单一职责原则
- Java设计模式之二十七(单一职责原则)
- JAVA设计模式之单一职责原则
- java 设计模式六大原则(1):单一职责原则
- JAVA设计模式-单一职责原则
- Java设计原则—单一职责原则(转)
- Java七大设计原则之单一职责原则
- Java设计模式—单一职责原则(SRP)
- java设计模式-单一职责模式,依赖倒转原则
- java 设计模式六大原则(1):单一职责原则