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

Question

Допустим, я определяю игровой класс, который реализует два разных представления:

interface IPlayerView {
    void play();
}

interface IDealerView {
    void deal();
}

Вид, который видит игра при игре в игру, и вид, который видит дилер при игре в игру (то есть игрок не может делать действия дилера, а дилер не может делать действия игрока). Определение игры следующее:

class Game : IPlayerView, IDealerView {
    void play() { ... }
    void deal() { ... }
}

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

public Game GetGame() { ... }

У меня было бы что-то вроде

public IPlayerView GetGame() { ... }

Но после некоторых тестов я понял, что если я позже попробую этот код, он будет работать:

IDealerView dealerView = (IDealerView)GameClass.GetGame();

это работает и позволяет пользователю действовать в качестве дилера.

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

Спасибо

Answer 1

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

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

Всегда будет способ злоупотребить вашим кодом. Если не через кастинг, то с отражением. Просто отпустите его и сконцентрируйтесь на создании "следующей большой вещи".

Answer 2

Я не думаю, что многого можно добиться, если использовать 2 различных метода play () и deal (), потому что тогда вы на самом деле не выполняете полиморфизм во время выполнения.

Концептуально, что вам нужнометод play (), но с разными реализациями для классов Player и Dealer.С высокого уровня, как дилер, так и игрок играют в игру, следовательно, метод play (), но то, как они на самом деле играют в него, отличается, когда дилер раздает (карты) и игрок делает ставки.

Таким образом, в соответствии с тем, что сказал Георгий, лучше изменить дизайн и сделать его более логичным и более простым для начала. Обычно я стараюсь максимально упростить процесс запуска, в любом случае они имеют тенденцию перегружаться и перегружаться в будущем.итераций.

Answer 3

Создайте классы реализации для Views, а затем передайте View Object в Factory Object и используйте эту Factory для получения соответствующих представлений. Завтра, если вам потребуется реализовать еще одно представление, вы можете легко улучшить.