OO Design Patterns with Perl

Question

В настоящее время я планирую дизайн новой системы, мне нужно будет закодировать код, взаимодействующий с внутренним API. Я рассматривал композицию объекта и наследование и решил, что самой правильной процедурой в моей ситуации было бы идти с композицией над наследованием, поскольку мои объекты имеют «отношение» друг к другу, а не «есть».

Теперь я нахожу, что, поскольку некоторые объекты зависят от других, могут быть случаи, когда «объект A» имеет атрибут, который является «объектом B» и атрибутом «объект C», однако «объект B» также имеет атрибут «объект C».

В надежде, что эта аналогия будет сделать больше смысла:

Допустим, у меня есть компания, которая продает коробки, который содержит кошек и радиоактивные вещества внутри них, которые не могут или никогда не вступают в реакцию:

Я продаю мой продукт организациям. Пользователи регистрируются у меня, указав организацию, к которой они принадлежат. У организации может быть много пользователей или нет. У пользователя должна быть организация, к которой она принадлежит. Я отслеживаю свой продукт (ящик как сущность и кошка (ов) как сущность) и к какой организации они принадлежат. Я также отслеживаю кошек и коробки, в которых они находятся. У организации может быть много коробок с множеством кошек в любом из них. Коробки могут быть пустыми. Некоторым пользователям разрешено покупать новые ящики, а другим разрешено смотреть на них.

Аутентификация & Авторизация управляется API, с которым я взаимодействую.

Насколько объектные отношения идут:

$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 

Сейчас:

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

И

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

ИЛИ

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

Что было бы правильным решением? Существуют ли другие аспекты, которые я не рассматриваю, которые могут сделать один вариант более жизнеспособным, чем другой?

В этой системе я буду использовать шаблон дизайна MVC с использованием Perl Catalyst и Moose.

Спасибо всем, кто внес свой вклад.

Answer 1

Вы должны задать себе один вопрос. Имеет ли значение для кошки, к которой принадлежит организация или кошка?

Например, если у вас есть объект кошки, вам даже нужно знать его владельца? Есть ли функциональность, которая начинается с кошки, и делает что-то специфическое для владельца - БЕЗ знания владельца, прежде чем вы даже знаете объект кошки?

E.g.типичная функциональность всегда будет начинаться с пользователем:

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

Действуйте найти своих кошек

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

А потом что-то делать с одним из кошек:

$cats[0]->CheckHealth(); 

Обратите внимание на важный факт : к тому времени, как вы попадете к конкретному коту, вы уже ЗНАЛИ организацию, поскольку именно так вы получили объект кошки. Нужно хранить $org внутри объекта $cat.

То же самое верно для кошек в коробках. Вам НИКОГДА не нужно найти коробку с кошачьим предметом, не зная, что некоторая кошка еще не в коробке?

Если шаблон функциональности имеет место (как это почти всегда бывает), у вас есть очень смирительная вперед объектную модель:

• Пользователь: Атрибуты «орг» и некоторые другие вещи
• Org: Атрибуты «UnboxedCatList» и «BoxList» - это массив кошек, которые еще не были привязаны к ящикам; один массив из коробки объектов
  • Одним из методов является PlaceUnboxedCatIntoBox()
• Box: Атрибуты "Catlist" (массив объектов кошки)
• Cat: Атрибуты кошек конкретного - кошачий дон 'собственные коробки или орг.