Назначение ответственности: игра, в которой есть игроки, у каждого из которых есть банковский счет.

Bank должен иметь контроль над BankAccounts, а не над player объектами.

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

Это так, что вы можете делать такие вещи, как:

bank.WithDrawMoney(player, amount);

or

bank.TransferMoney(playerFrom, playerTo, amount);

В этом случае банк «найдет» счет, который есть у этого игрока, и удалит с него соответствующие средства.

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

Итак, на верхнем уровне у вас будет Game, который содержит такие объекты, как Players, Bank и Board. У него могут быть лучшие методы, такие как RollDice(). Совет может иметь такой метод, как Move(player, distance);

playerObject.getAccount().withdraw() нарушает "Закон" Деметры.

Предоставьте методы Player и т. д., которые имеют смысл для игрока. Изучите инверсию управления для работы с зависимостями.

Я думаю, вы хотите задать себе этот вопрос: является ли учетная запись, которой владеет игрок, публичной собственностью игрока? Если да, возможно, getAccount() — неплохой вариант.

В конце концов все сводится к балансу. Если класс вашей учетной записи имеет 20 методов/свойств (давайте проигнорируем аргументы о том, является ли 20 большим числом), то очевидно, что с точки зрения кодирования наличие одной функции player.getAccount() будет дублировать намного меньше кода, чем наличие 20 функций в проигрывателе. которые просто переадресовывают звонки на счет.

С другой стороны, вы должны помнить, что getAccount() теперь связывает реализацию вашего игрового класса с тем фактом, что у каждого игрока должна быть учетная запись a. У вас не может быть игроков, у которых нет банковских счетов.

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

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

Что бы это ни стоило, я обычно считаю продуктивным попытаться начать думать в проблемной области, а не в коде, как это было затронуто другими.

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

Я понимаю, что вы заявили, что у вас есть класс банковского счета, но если процесс заключается в том, что Джо Блоггс действительно платит наличными (из своего тайника в бачке унитаза) Фреду, не имея никакого отношения к банку, тогда он не собирается нужен счет в банке. Если затем Фред решит в какой-то момент положить его в банк, а не продолжать запихивать его под матрас (или игровую доску), то в этот момент ему понадобится банк и счет.

Предполагая, что player может получить/получить доступ к другим игрокам, первый процесс увидит (в Player) что-то вроде:

void payPlayer( player, amount )
{
  spendCash( amount ); // reduces stash by "amount"
  player.recieveCash( amount );

}

Размер тайника с деньгами может быть просто атрибутом класса игрока.

Второй вид деятельности — это совсем другое. Теперь Фред должен сначала сообщить своему банку, что он хочет внести 100 долларов, а затем его банк либо через дырку в стене, либо через кассира (надеюсь) кредитует его Счет. Так что Фреду сейчас действительно нужен банк и, возможно, счет. Но зачем ему нужна учетная запись? Какой цели он служит в игре? Это обязательно необходимый компонент программы или он просто есть, потому что в реальной жизни деньги уходят в банки?

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

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