代码之家 › 专栏 › 技术社区 › vicky

单一责任原则有什么用?

design-principles single-responsibility-principle solid-principles oop

4

vicky · 技术社区 · 7 年前

我试图理解单一责任原则,但我很难理解这个概念。我正在读一本书“Java设计模式和最佳实践”,作者:Lucian Paul Torje;Adrian Ianculescu;Kamalmeet Singh

他们说Car既有Car逻辑,也有数据库操作。在将来,如果我们想更改数据库,那么我们需要更改数据库逻辑,并且可能还需要更改car逻辑。反之亦然。。。

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

我的问题是,即使我们创建了两个类,让我们考虑一下我们正在向类CAR添加一个名为price的新属性(或者将属性模型更改为carModel),那么您不认为我们还需要像更改SQL之类的更新CarDAO类吗。

那么SRP在这里有什么用呢?

3 回复 | 直到 7 年前

1

8

James Lim 7 年前

好问题。

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

例如,假设您希望将数据库从MySQL交换到PostgreSQL。使用SRP,您将重新实现 CarDAO ,更改所使用的特定于方言的SQL,并保留 Car

在另一个例子中,假设您希望将CarDAO委托给另一个开发人员与memcached集成,这样虽然最终是一致的,但读取速度很快。同样,这个开发人员不需要知道任何关于在里面 小型车 卡道 卡道 具有不同一致性保证的API。

业务逻辑 使用我们的任何一个表;相反,它们的突变跟踪魔法可以灵活地注入到dao中,使用decorator或其他方面编程技术。(顺便说一句,这也可以在SQL接口的另一端完成。)

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

小型车 卡道 公共界面。)哎呀,我的伤疤可能正在显现。

一个推论是,如果你需要改变在里面 小型车 (比如说,加上一个计算每辆特斯拉在令人尴尬的召回事件后的较低售价的方法),你就不会去碰 ,自 if car.brand == 'Tesla; price = price * 0.6 与数据访问无关。

CQRS

2

Ivan 7 年前

对于添加新属性,只有当属性应该保存到数据库时,才需要更改这两个类。如果它是业务逻辑中使用的属性,则不需要更改DAO。另外,如果您将数据库从一个供应商更改为另一个供应商,或者从SQL更改为NoSQL,则只需在DAO类中进行更改。如果您需要更改某些业务逻辑,那么只需更改 Car

3

2

Mick Mnemonic 7 年前

Single responsibility principle 正如罗伯特·C·马丁所说

一个类应该只有一个改变的理由。

牢记这一原则通常会导致更小和高度内聚的类,这反过来意味着需要同时处理这些类的人更少,代码变得更健壮。

在你的例子中 数据存取 和 业务逻辑 (价格计算)逻辑分离意味着您在进行更改时不太可能破坏另一个。