oop - 单一责任原则有什么用？

Question

我试图理解单一职责原则，但我很难掌握这个概念。我正在阅读 Lucian-Paul Torje；Adrian Ianculescu；Kamalmeet Singh 所著的“Java 中的设计模式和最佳实践”一书。

在这本书中，我正在阅读单一职责原则章节，
他们有一个汽车类，如下所示:



他们说 Car 既有 Car 逻辑又有数据库操作。将来如果我们想更改数据库，那么我们需要更改数据库逻辑，并且可能还需要更改汽车逻辑。反之亦然...

解决方案是创建两个类，如下所示:



我的问题是，即使我们创建了两个类，让我们考虑我们正在向 CAR 类添加一个名为 'price' 的新属性 [或将属性 'model' 更改为 'carModel' ] 那么你不认为我们还需要更新CarDAO 类之类的改变SQL 之类的。

那么这里的 SRP 有什么用呢？

Answer 1

好问题。

首先，请记住，这是本书中的一个简单示例。读者可以对此进行一些扩展并想象更复杂的场景。在所有这些场景中，进一步假设您不是团队中唯一的开发人员；相反，您在一个大型团队中工作，开发人员之间的沟通通常采用协商类接口(interface)的形式，即 API、公共(public)方法、公共(public)属性、数据库模式。此外，您经常需要担心回滚、向后兼容性以及同步发布和部署。

例如，假设您想将数据库从 MySQL 换成 PostgreSQL。使用 SRP，您将重新实现 CarDAO ，更改使用的任何特定方言的 SQL，并保留 Car逻辑完好。但是，您可能需要在配置中进行一些小改动，以告诉 Car 使用新的 PostgreSQL DAO。一个合理的 DI 框架会让这一切变得简单。

假设在另一个示例中，您希望将 CarDAO 委托(delegate)给另一个开发人员以与 memcached 集成，这样读取虽然最终是一致的，但速度很快。同样，此开发人员不需要了解 Car 中的业务逻辑。 .相反，它们只需要在 CarDAO 的 CRUD 方法后面进行操作。 ，并可能在 CarDAO 中声明更多方法具有不同一致性保证的 API。

假设在另一个示例中，您的团队聘请了一位专门从事合规法律的数据库工程师。在为即将到来的 IPO 做准备时，数据库工程师的任务是保存公司 35 个数据库中所有表的所有更改的审计日志。有了 SRP，我们勇敢的 DBA 就不必担心使用我们的任何表的任何业务逻辑；相反，它们的变异跟踪魔法可以巧妙地注入(inject)到整个 DAO 中，使用装饰器或其他方面编程技术。 (顺便说一句，这也可以在 SQL 接口(interface)的另一端完成。)

好的，最后一个 - 假设现在团队中有一名系统工程师，负责跨 AWS 中的多个区域(数据中​​心)分片这些数据。该工程师可以进一步采用 SRP 并添加一个组件，该组件的唯一作用是为每个 ID 告诉我们每个实体的主区域。每次我们进行跨区域读取时，新组件都会碰到一个计数器；每周，一个自动化工具都会将跨区域频繁读取的数据迁移到新的主区域，以减少延迟。

现在，让我们进一步想象，假设业务正在蓬勃发展——突然间，您正在为一家拥有多个部门跨越多个国家的财富 500 强公司工作。财务部的业务分析师希望使用您的表格在其 IPO 后投资者报告中绘制汽车销售季度增长情况。而不是让他们访问Car (因为用于报告的逻辑可能与用于准备数据以在 Web UI 上呈现的逻辑不同)，您可以为 CarDAO 创建一个只读接口(interface)。包含精心策划的公共(public)属性的简短列表，您现在必须跨部门维护这些属性。上帝禁止你必须重命名这些属性之一:为 3 个月的日落计划和许多悲伤的仪表板和深夜升级做好准备。 (并且请不要让他们直接访问实际的 SQL 表，因为隐含的假设是整个表都是公共(public)接口(interface)。)哎呀，我的伤疤可能正在显现。

一个推论是，如果您需要更改 Car 中的业务逻辑(比如说，添加一个方法来计算尴尬召回后每辆特斯拉的较低售价)，你不会碰CarDAO , 自 if car.brand == 'Tesla; price = price * 0.6与数据访问无关。

补充阅读:CQRS