[译]设计原则之单一职责原则

设计原则之单一职责原则

在面向对象软件开发中，SOLID 是最受欢迎的设计原则之一。其是下面 5 个设计原则为方便记忆的首字母缩写。

• 单一职责原则
• 开/闭原则
• 里氏替换原则
• 单一接口原则
• 依赖倒置原则

它们全都被广泛使用并且值得了解。但是在我的这一系列的第一篇，主要关注第一条：单一职责原则。

Robert C. Martin 这样描述其：

一个类有且仅有一个原因去改变。

即使你从未听说过 Robert C. Martin  其人或者其著作，大概也会听过或者用过这一原则。这是大多数开发者在构建稳健的可持续的软件工程中会使用到的基本的原则之一。你不仅可以将其应用在类上，也可以将其用在软件组件和微服务中。

单一职责原则的优点

在更深入这个设计原则之前，让我们先来提一个最重要的问题：为什么使用该原则？如果忽视其会导致什么？

关于单一职责的原则的争论相当简单：它使你的软件易于实现并且避免了将来修改时不可预知的负面影响。

变化的频率和影响

我们都知道随时都有修改需求的可能性。每次修改也至少改变了一个类的职责。你的类负有越多的职责，需要被修改的可能性越大。如果你的类负有很多职责，他们彼此便不再独立。

它们的职责一旦改变，你就要去修改它。显然，如果它只有一个职责，那么你去修改它的可能性要大为降低。

这也许不算个事儿，但是它也对所有依赖它的类或者组件产生影响。由于你的修改，你或许需要更新依赖或者重编译被依赖的类即使它们并未直接受到修改影响。它们只是使用了你的类的其他职责，但你不得不去更新它们。

此外，你需要经常修改你的类，每次的修改将变得越来越复杂，越来越多的负面影响，以及付出超出本该需要的工作量。因此，最好通过确保每个类只有一个职责来避免这些问题。

易于理解

单一职责原则还提供了另一个潜在的好处。较之于一个类，软件，组件提供所有的解决方案，只承担一个职责要更加易于表述，理解和实现。这减少了 bug，提高了你的开发速度，并且使你的生活像软开发一样更加闲适。

一个简单的问题去检验你的设计

不幸地是，遵循单一职责原则不似听起来那样容易。

如果你构建项目已经有很长的一段时间，那么修改需求时，似乎最容易也最快的方式是往现有的代码中加一个方法或者功能，而非写一个新的类或者组件。但是这样就会使一个类承担更多的职责，继而有损软件的可维护性。

在做任何修改之前，你可以问一个简单的问题来避免这些问题：你的类/组件/微服务的职责是什么?

如果你的答案包括单词 "and"，那么你很可能破坏了单一职责原则。然后最好后退一步，重新思考你当前的方式。很可能存在更好的实现方式。

单一职责原则真实案例

你可以找到很多关于五大设计原则的案例在开源软件和大多是设计良好的应用中。比如你最可能去实现的 java 持久层和流行的框架和规范。

其中一个是 JPA。它有且仅有一个职责：给通过使用对象关系映射（ORM）的概念定义一个在关系型数据库管理数据持久化的标准。

那是一个很大的职责。规范定义了很多不同的接口，详细说明了实体生命周期状态和转变，甚至提供了一个查询语言：JPQL。

但是那是 JPA 规范仅有的职责。在你的应用中，其他功能可能需要实现诸如校验，REST APIs 或者日志，并不是 JPA 的职责。你需要引入其他规范或者框架来提供这些功能。

如果你再深入 JPA 规范一点，你会发现当中更多的单一职责案例。

JPA EntityManager

EntityManager 接口提供了一组方法从数据库持久，更新，移除和读取实体。它的职责是管理和当前持久化上下文相关的实体。

那是 EntityManager 唯一的职责。它没有实现任何业务逻辑或者校验或者用户授权。甚至用于 JPA 的特定的注解，作用于应用指定的实体模型，都不是 EntityManager 的职责。因此，只有当全局通用的持久化定义改变，其才需要改变。

 未完待续 。。。

原文地址：

传送门

 

 

 

 

 

转载于:https://www.cnblogs.com/wangliangwu/p/8659262.html