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

Question

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

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

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

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

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

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

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

Answer 1

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

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

• Факт IMembership агрегаты userAccount не имеет смысла, он не должен знать учетные записи

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

Это ненормально атрибуты drawLimit и TransfertLimit присутствуют в четырех классах членства, они должны присутствовать только в IMembership , чей должен быть абстрактный класс, а не интерфейс

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

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

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

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