考虑架构....
我通常有一个带有 addItem 和 removeItem 方法的购物车类（以及其他几个方法）。然而，本着现实世界 shananigans 购物车的精神，客户应该对购物车采取行动 - 因此 addtoCart / removefromCart 不应该是客户的一种方法吗？
或者我应该有一个中间的 CustomerActsOnCart 对象，它将客户和购物车对象作为构造函数中的参数并在那里执行操作？？？
欢迎任何思考......
【问题讨论】：
标签： php oop architecture
我看到它的方式... Customer 类和 Cart 类之间具有 1x1 关系，因此您可以将 Customer 对象的引用放在 Cart 中.. 或将 Cart 对象放在 Customer 中，我会说最好使用第二个选项，因为它会更容易获得当前用户，然后你可以执行以下操作：
$current_user->getCart()->addtoCart()
并将 addtoCart/removeItem 方法保留在 Cart 对象中
希望对你有帮助
【讨论】：
即使您将方法addToCart() 和removeFromCart() 提供给Customer，您仍然必须在ShoppingCart 中有一些逻辑，才能让这些方法在添加或删除项目时实际进行状态更改。 IMO，在这种情况下，参与者通过引用拥有客户和/或反之亦然更好地表示，例如
$cart = new ShoppingCart;
$cart->setOwner(new Customer);
$cart->addItem(new Item('Apples'));
$cart->checkout();
您也可以从客户那里解决这个问题，例如
$customer = new Customer;
$customer->setShoppingCart(new ShoppingCart);
$customer->addItemToShoppingCart(new Item('Apples'));
$customer->checkout();
但是方法名称addItemToShoppingCart 已经暗示Customer 作用于ShoppingCart，所以在里面你很可能在做
$this->getShoppingCart()->addItem($item);
如果 ShoppingCart 是 composite element 或 Customer 的 Customer，我们希望隐藏其实现细节，我们可以使用类似的方法，但由于 ShoppingCart 不是 IMO 的重要组成部分，因此此方法不应该是客户的重要组成部分在客户身上。它只是一个方便的代理。
您可以为Customer 创建一个Decorator 来处理购物行为。这会将 How-To-Shop 的 concern/responsibility 与客户分离，例如像
class ShoppingDecorator
{
protected $actor;
protected $cart;
protected function __construct($actor) { ... }
public function getCart() { ... };
public function addToCart() { ... }
...
}
这还允许您将购物行为应用于可能需要此行为的其他参与者。
CustomerActsOnCart 方法听起来有点像Mediator Pattern。不确定这是否是一种可行的方法。
【讨论】：