SOLID 原则：单一职责原则
SOLID 原则：单一职责原则
每个班级应该有一个责任，一个单一的目的
这意味着什么？
我相信通过示例进行教学，所以让我们直接进入。
笔记：
- 每个功能的实现都故意做得不好
- 永远不应使用此代码
- 我们只关心谁负责某些功能，而不关心该功能是如何工作的。
- 我还制作了一个描述相同概念的 YouTube 视频： https://www.youtube.com/watch?v=r2LZBJ-cS4M&t=4s .
执行不力
badImplCustomer
这是怎么回事？
好吧，我很高兴你问。
结构 badImplCustomer 包含名称和地址，这对客户来说是有意义的。它还包含 Order 和 OrderComplete 状态。如果你质疑它，那么你就在正确的道路上。
我们还看到了 3 个函数：addOrder、calculateBill、deliverOrder。只是提醒一下，我们不关心功能。
似乎我们根本不尊重单一职责。客户结构负责存储客户信息、创建订单、计算账单和交付订单。想象一下，我们添加了更多功能。这个物体会变得很大。单元测试、拆分包、让多个团队拥有它会变得很困难。更改对象的某些部分可能会对其他功能产生意想不到的后果。知道可用的功能将变得很困难。
似乎基于代码，我们可以将其拆分为更小的部分。让我印象深刻的是 顾客信息 , 命令 ， 和 送货 .
让我们看一个理想的实现。
理想的实现
让我们专注于接口。接口基本上是合约 结构/类 必须坚持传递给接口的消费者。
顾客信息
这 姓名 和 地址 由接口强制执行，这就是 命令 目前。后来，也许一个 家庭 struct 将实现接口。该接口强制它只关心提供客户信息的责任。
完成订单
我们在这里看到一个方法 完全的 .从本质上讲，它会将订单标记为已完成。我们现在不会进入接口的最佳实践，但我们可以看到它目前满足了我们的需求。如果界面发生变化，将来只会因为一个原因发生变化，即更改如何将订单标记为完成。
Order 结构仅包含与订单相关的详细信息和方法。计费是否属于订单是有争议的。支付账单后，订单通常被视为已完成。
送货
我知道这不是一个界面。所有这一切都在乎交付订单。交付完成后，它将订单标记为已完成，但它不知道有关订单的任何实施，因此履行单一责任。它做它需要考虑交付的产品。
结论
我希望上面的文章清楚地说明了如何 单一责任 作品。我们可以很容易地看到应用程序的各个部分以及它是如何工作的。测试这也容易得多。我们看到了什么是糟糕的实现以及如何解决它。
请在下面留下任何反馈（好或坏）。很想学习如何改进。下一站是 ** ○**
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
