Разработка UML-диаграммы банковского счета и членства (проектирование ОО)

Я разрабатываю систему членства в бэк-аккаунте с диаграммой UML.

Моя идея состоит в том, чтобы создать класс userAccount и 2 подкласса savingAccount и currentAccount, которые наследуют userAccounts

С членством я создал интерфейс членства Membership и реализовал 3 класса, Gold, Silver, Bronze.

Поэтому я хотел, чтобы у разных участников были разные лимиты на снятие средств и лимиты на переводы для обеих учетных записей, но только interestRateCalculation() будет применяться к классу savingAccount.

Я реализовал диаграмму UML, как показано на рисунке.диаграмма UML

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

Я хотел бы знать, что является более точным способом реализации диаграммы. Очень признателен.


oop system-design uml
person ThomasDaNerd    schedule 12.04.2020    source источник
comment
Я могу себе представить, что такое учетная запись Saving(s), но что такое учетная запись Current?? Может валюта? Также: в соответствии с общепринятым соглашением имена классов должны начинаться с заглавной буквы.   -  person qwerty_so    schedule 12.04.2020
comment
Ха, это опечатка, спасибо за напоминание :)   -  person ThomasDaNerd    schedule 13.04.2020

Ответы (1)


arrow_upward
1
arrow_downward

Все, что я вижу в классах членства, кажется независимым от какой-либо учетной записи, если это правда:

  • Во всей системе есть только 1 экземпляр каждого подкласса, поэтому всего их 3, и каждый является синглтоном.

  • Тот факт, что IMembership объединяет userAccount, не имеет смысла, он не должен знать учетные записи.

  • Вероятно, учетная запись связана с одним и только одним из трех синглетонов, что позволяет учетной записи знать пределы и способы расчета процентов. В этом случае у вас есть направленная связь от userAccount до IMembership.

Ненормально, что атрибуты withdrawLimit и transfertLimit присутствуют в четырех классах членства, они должны присутствовать только в IMembership, который должен быть абстрактным классом. а не интерфейс

Для меня userAccount должен быть абстрактным классом, потому что у вас не может быть учетной записи, которая не является одним из двух подклассов.

Операции getWithdrawLimit и getTransfertLimit зависят только от членства, поэтому они определены в userAccount, а не в подклассах, конечно, эти операции вызывают соответствующий в связанном экземпляре членства.

введите здесь описание изображения

(я не определял конструктор для экономии времени)

Да, в случае currentAccount вычисление процентов бесполезно, но если вы хотите избежать дублирования классов членства, направленная ассоциация с членством не находится в userAccount< /em>, но каждый подкласс и операции getWithdrawLimit и getTransfertLimit являются абстрактными в userAccount. Это сложнее, и я не думаю, что это стоит усилий.

person bruno    schedule 12.04.2020
comment
Спасибо чувак. Очень хорошо объяснил. Ваша помощь очень ценится! :) - person ThomasDaNerd; 13.04.2020