Использование обобщения над агрегацией

Question

У меня есть модель этого класса, в которой Банк - это класс, который сейчас используется для компьютеризированной банковской сети.Это должен быть банкомат (банкомат), а также кассир.

Я использовал обобщение и взял класс с именем AccountHandlers , который наследует Банк класс.Для этого AccountHandlers дополнительно агрегированы ATM и HumanCashier .

Теперь дело в том, что мой друг утверждал, что я все понял неправильно.По его словам, AccountHandlers должен быть агрегирован в Bank , а ATM и HumanCashier должны наследоваться в AccountHandlers .

Я немного смущен этим.Как я могу смоделировать это !!или оба метода верны?

Answer 1

Я бы вернулся к основам.

Вы должны спросить себя, является ли ATM AccountHandler, или * AccountHandler имеет ATM.Это должно дать вам общий ответ на вопрос об использовании наследования или композиции.

И то, и другое будет правильным .Только один будет хороший дизайн , и это зависит от того, что пытается сделать ваше приложение.

Как правило, существует практическое правило (взятое из Effective Java), которое утверждает, чтоследует отдавать предпочтение композиции, а не наследованию.Возьмите это с долей соли и убедитесь, что вы разрабатываете свое приложение правильно.(Для получения дополнительной информации см. Предпочитаете композицию наследованию? )

Answer 2

Обычно наследование (или специализация) используется для моделирования отношения " is-a ", а агрегация / композиция используется для отношений " has-a ".

Теперь вы можете спросить себя, какой из них правильный:

• обработчиком счета является банк или в банке есть один или несколько обработчиков счета
• человек-кассир является (специальным видом) обработчиком счета или обработчик счета имеет человека-кассира

На мой взгляд, смелые утверждения верны. Поэтому вам следует использовать агрегацию или состав для банка-> обработчиков счетов и наследование для обработчика счетов-> кассир.

Answer 3

Если это работает, это правильно. Не увлекайтесь пустой тратой времени на UML-моделирование. Напишите прототип, и любые недостатки дизайна скоро станут очевидными.

Answer 4

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

Несмотря на то, что вы делаете , пожалуйста, напишите модульные тесты вокруг вашей реализации . Потому что при таких заблуждениях вы, вероятно, измените структуру класса, и в это время ваши модульные тесты гарантируют, что вы можете плавно пересмотреть код.