OO Design Patterns avec Perl

Question

Je suis actuellement en train de planifier la conception d'un nouveau système que je devrai coder pour interagir avec une API back-end. Je pensais à la composition et à l'héritage de l'objet et j'ai décidé que la procédure la plus correcte dans ma situation serait d'utiliser la composition plutôt que l'héritage car mes objets ont une relation «a» et non un «est un». Je trouve maintenant cependant que parce que certains objets dépendent d'autres, il peut y avoir des cas où "l'objet A" a un attribut qui est "l'objet B" et un attribut "l'objet C" - cependant "l'objet B" a aussi un attribut "objet C".

Dans l'espoir que cette analogie serait plus logique:

Disons que j'ai une entreprise qui vend des boîtes qui contiennent des chats et des substances radioactives à l'intérieur d'entre eux qui peuvent ou ne réagiront:

Je vends mon produit aux organisations. Les utilisateurs s'inscrivent avec moi en spécifiant une organisation à laquelle ils appartiennent. Une organisation peut avoir plusieurs utilisateurs ou aucun. Un utilisateur doit avoir une organisation à laquelle il appartient. Je garde la trace de mon produit (la boîte en tant qu'entité et le (s) chat (s) en tant qu'entité) et l'organisation à laquelle ils appartiennent. Je garde aussi une trace des chats et des boîtes dans lesquelles ils se trouvent. Une organisation peut avoir beaucoup de boîtes avec beaucoup de chats dans chacune d'elles. Les boîtes peuvent être vides. Certains utilisateurs sont autorisés à acheter de nouvelles boîtes tandis que d'autres sont autorisés à les regarder.

Authentification & L'autorisation est gérée par l'API avec laquelle j'interagis.

En ce qui concerne les relations d'objet vont:

$user has a => $organization that it belongs to 

$user has a => $role that dictates what it may or may not do. 

$box has a => $organization that it belongs to 

maintenant:

$cat has a => $box that it belongs to 

ET

$cat has a => $organization that it belongs to ? 

OU

$cat has a => $box that it belongs to WHICH has a => $organization that it belongs to 

Quelle serait la décision de conception correcte ici? Existe-t-il d'autres aspects que je ne considère pas qui pourraient rendre une option plus viable que l'autre?

Je vais mettre en œuvre un modèle de conception MVC dans ce système en utilisant Perl Catalyst et Moose.

Merci à tous d'avance pour vos contributions.

Answer 1

Vous devez vous poser une question. Est-ce important pour un chat à quelle organisation appartient un chat ou une boîte? Par exemple, quand vous avez un objet chat, avez-vous besoin de connaître son propriétaire? Y at-il une fonctionnalité qui commence avec un chat, et fait quelque chose de spécifique au propriétaire - SANS connaître le propriétaire avant même de connaître l'objet de chat?

E.g.une fonctionnalité typique toujours commencer par un utilisateur:

my $org = $user->org(); 

Continuer à trouver ses chats

my @cats = $org->listOwnedCats(); 

Et puis faire quelque chose avec l'un des chats:

$cats[0]->CheckHealth(); 

Notez le fait important : au moment où vous arrivez au chat spécifique - vous connaissez déjà l'organisation puisque c'est ainsi que vous avez obtenu l'objet chat en premier lieu. Il n'y a aucun besoin de stocker $org à l'intérieur de l'objet $cat.

Il en va de même pour les chats dans les boîtes. Avez-vous JAMAIS besoin de trouver la boîte d'un chat en plus de savoir qu'un chat n'est pas encore emballé?

Si ce modèle de fonctionnalité détient (comme presque toujours fait), vous avez un modèle objet très détroit vers l'avant:

• utilisateur: Les attributs sont « org » et quelques autres trucs
• Org: Attributs sont "UnboxedCatList" et "BoxList" - l'un est un tableau de chats qui n'ont pas encore été assignés à des boîtes; on est un tableau de boîte objets
  • L'une des méthodes est PlaceUnboxedCatIntoBox()
• Box: Les attributs sont "catlist" (tableau d'objets de chat)
• Cat: Les attributs sont spécifiques chat - don de chat ne possèdent pas de boîtes ou d'orgs.