php acteur oop pour agir sur l'objet

Question

architecture Considérant ....

J'ai normalement une classe de panier avec des méthodes AddItem et removeItem (parmi quelques autres). Toutefois, dans l'esprit du monde réel, les chariots doivent être utilisés par les clients. Par conséquent, l'addtoCart/removefromCart ne doit-il pas être une méthode pour le client?

OU devrais-je avoir un objet itermediate CustomerActsOnCart qui prend les objets client et panier comme arguments dans le constructeur et y effectue la manipulation ???

Les songeries seraient les bienvenus ...

Answer 1

Même si vous donnez un Customer les méthodes addToCart() et removeFromCart(), vous devez toujours avoir une certaine logique dans ShoppingCart d'avoir ces méthodes font réellement le changement d'état lorsqu'un élément est ajouté ou supprimé. OMI, l'acteur dans ce cas est beaucoup mieux représenté par une référence au client propriétaire et/ou viceversa, par exemple.

$cart = new ShoppingCart; 
$cart->setOwner(new Customer); 
$cart->addItem(new Item('Apples')); 
$cart->checkout(); 

Vous pouvez également vous en servir auprès du client, par ex.

$customer = new Customer; 
$customer->setShoppingCart(new ShoppingCart); 
$customer->addItemToShoppingCart(new Item('Apples')); 
$customer->checkout(); 

Mais le nom de la méthode addItemToShoppingCart implique déjà que les Customer agit sur un ShoppingCart, donc à l'intérieur vous font probablement

$this->getShoppingCart()->addItem($item); 

Si ShoppingCart était un composite element de Customer pour laquelle nous voulions cacher les détails de mise en œuvre , nous pourrions utiliser quelque chose comme ça, mais puisque le ShoppingCart est OMI pas une partie essentielle d'un client cette méthode ne devrait pas être sur le client. Ce n'est rien d'autre qu'un proxy de commodité.

Vous pouvez créer un Decorator pour le Customer pour gérer le comportement de magasinage. Cela désaccouple le concern/responsibility de Comment-Pour-Boutique auprès du Client, par ex. Quelque chose comme

class ShoppingDecorator 
{ 
    protected $actor; 
    protected $cart; 
    protected function __construct($actor) { ... } 
    public function getCart() { ... }; 
    public function addToCart() { ... } 
    ... 
} 

Ceci vous permettrait également d'appliquer le Comportement Shopping à d'autres acteurs qui pourraient avoir besoin de ce comportement. L'approche CustomerActsOnCart ressemble un peu à la Mediator Pattern. Je ne sais pas si c'est une approche réalisable.

Answer 2

la façon dont je le vois ... une classe à la clientèle et une classe de panier ont une relation 1x1 entre eux, vous pouvez donc mettre une référence de l'objet client dans le panier .. ou mettre un objet panier dans le client, je dirais qu'il est préférable d'utiliser la deuxième option parce qu'il serait plus facile d'obtenir l'utilisateur actuel et vous pourriez faire quelque chose comme:

$current_user->getCart()->addtoCart() 

$current_user->getCart()->addtoCart() 

et conserver les méthodes addtoCart/removeItem dans l'objet Cart

espère que cela aide