Php 面向对象的检验过程设计

在过去的两个小时里，我的同事和我一直在讨论，试图找出设计新网店的最佳方式，该网店处理客户的购物篮，但我仍然不确定我们是否得出了一个好的结论

这听起来像是一个相当基本的问题，但我们发现实际上系统的不同部分之间存在大量的相互依赖关系

这些部分（到目前为止！）包括：

• 购物篮（跟踪客户选择购买的产品）
• 交易（定义产品的促销活动，如“以20英镑购买3个x”，或“购买2个x，免费获得1个”）
• 低订单费用（在一定值下，订单中会增加额外费用）
• 运费（基于一系列选项）
• 兑换券
• 客户信用（客户的账户上可能有信用，从订单总额中减去）

我非常担心所有这些对象相互交谈，从彼此那里获取价值，然后根据这些价值行事。我在想象它会变成一个巨大、复杂、无法维护的纸牌屋

我确信让系统的不同部分直接相互对话是一种糟糕的做法，更不用说允许它们改变彼此的状态（不管它们是如何做的），因为系统的各个部分在运行时依赖于处于不同状态的其他部分，如果它们都可以相互对话，我不能肯定有些东西没有改变我所依赖的其他东西

但是有很多例子我看不到其他的方法。例如：

• “免费购买X，免费获得Y”的交易需要在客户签出X时将Y产品添加到购物篮中。因此，交易有效地影响了篮子
• 确定是否申请低订购费是基于篮子中产品的价值，但要在多次购买折扣之后（例如，2的价格是3）。因此，它需要考虑篮子，同时也要考虑交易
• 当客户浏览网站时，购物篮还需要显示一个总价值，这个总价值应该考虑到与产品相关的交易，而不是其他

---

我怎样才能做到这一点，而不伤自己的脚，编写可能会以意想不到的方式影响大量其他代码的代码？

您似乎有以下抽象实体：

• 篮子
• 交易
• 费用（低订单、运输）
• 学分（凭证、未付学分）

您可能可以将这些概念封装到单个业务逻辑类中，该类使用多个网关访问具体模型。乍一看，业务逻辑似乎是“将任何交易添加到篮子中，应用任何费用，然后赎回任何信用选项”。这些组件中的每一个似乎都是装饰师的集合，每个装饰师都有可能在篮子中发挥作用

这里的业务逻辑类的工作是获取每个网关（交易、费用、信用）并迭代它们各自的组件。每个组件都会被传递到篮子中，并询问它是否会影响篮子。如果篮子应该受到影响，那么应该应用效果，迭代可以继续

通过这种方式，业务逻辑被保存在一个地方，它定义了操作顺序。每个组件通过业务逻辑松散地耦合到篮子中

---

更新：。

到目前为止您尝试了什么？我建议你去看看S.O.L.I.d。此外，如果你要去TDD，你应该非常安全，它不会只是坏。