OO Design - Object задает вопрос классу, который косвенно его удерживает

Question

Мне интересно, является ли объект, задающий вопрос другому объекту, который косвенно его удерживает, «плохим» дизайном. Например ...

Требования: Персонаж (объект) движется по сетке. Когда он пытается переместиться в другое место, ему нужно знать, занято ли это место чем-то, что его блокирует, или эта часть сетки полностью недоступна. (Обратите внимание, что сам персонаж должен знать).

В приложении состояние содержит менеджер тайлов и менеджер персонажей. Менеджер тайлов знает, какие тайлы доступны, а какие нет. Менеджер персонажей знает расположение плиток персонажей.

Было бы разумно, чтобы персонаж вызывал функцию из состояния, скажем AuthorizeMovement, которая определяет, возможно ли перемещение через его TileManager и CharacterManager, и возвращает true, если да, false если нет?

Нарушает ли это какие-либо важные принципы, приводящие к неприятностям в будущем?

Очевидно, что это обобщено и сведено к тому, что необходимо для понимания проблемы.

Answer 1

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

... объект, задающий вопрос другому объекту, который косвенно его удерживает

Итак, объект «удержание» имеет ссылку на «удержание»«object», а также, чтобы «задать вопрос», «удерживаемому» объекту потребуется ссылка на «удерживающий» объект.

Это создает круговой график зависимости объекта и часто является запахом кода.

Казалось бы, какой-то другой класс должен нести ответственность за знание как о персонаже, так и о TileManager и / или CharacterManager.

Answer 2

Я не вижу проблемы.Хороший ОО Дизайн имеет много принципов.Но по своей сути у вас есть большая 4: инкапсуляция, наследование, полиморфизм и абстракция.Кроме того, вы хотите высокую когезию и низкое сцепление.Это означает, что ваши объекты / классы могут помещаться в любом месте и не привязаны к конкретной реализации или классу.

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

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

Answer 3

Это не противоречит принципам ООП.Детали вызова полностью абстрагированы, и вы все равно зависите от объекта State.Как еще вы могли бы реализовать эту функцию?

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