Дизайн OO - Объект задает вопрос классу, который косвенно содержит его
Я задаюсь вопросом, является ли объект, задавая вопрос другому объекту, который косвенно содержит его, "плохим" дизайном. Например...
Требования: Символ (объект) перемещается в сетку. Когда это пытается переместиться в другое пятно, это должно знать, занято ли то пятно уже чем-то, что блокирует его, или если та часть сетки абсолютно недоступна. (Обратите внимание, что сам символ должен знать).
В приложении состояние содержит tilemanager и charactermanager. tilemanager знает, какие мозаики доступны и которые не являются. charactermanager знает местоположения мозаики символов.
Это было бы разумно, чтобы символ вызвал функцию от состояния, скажите AuthorizeMovement, который определяет, возможно ли перемещение через свой TileManager и CharacterManager, и возвращает true если так, ложь если нет?
Это нарушает какие-либо важные принципы, ведя к проблеме в будущем?
Очевидно, это обобщено и разделено вниз к тому, что необходимо для понимания проблемы.
3 ответа
Не вижу проблемы. Хороший объектно-ориентированный дизайн основан на многих принципах. Но в его основе у вас есть большая четверка: инкапсуляция, наследование, полиморфизм и абстракция. Кроме того, вам нужна высокая степень сцепления и низкое сцепление. Это означает, что ваши объекты / классы могут поместиться где угодно и не привязаны к конкретной реализации или классу.
С учетом сказанного, похоже, что вы использовали описанное выше, чтобы инкапсулировать движение, а персонажи абстрагируют их в отдельные классы. Таким образом, ваш класс Character не изменяет доску напрямую, что было бы плохо, если бы это было так.
По мере того, как вы глубже понимаете свою проблему, вы всегда можете провести рефакторинг кода, чтобы улучшить дизайн и воспользоваться другими принципами.
Это не противоречит никаким принципам ООП. Детали вызова полностью абстрагируются, и вы в любом случае зависите от объекта State. Как еще вы могли бы реализовать эту функцию?
Абстракция и принципы - полезные инструменты. Но вы не должны полагаться на них, чтобы квалифицировать ваш код как хороший. Не каждая абстракция или каждый принцип подходят для каждого сценария или каждой возможной реализации. Это рекомендации, а не правила. Если вы не можете быстро найти альтернативную реализацию, используйте ее, а затем вернитесь к ней.
Я бы предположил, что это, скорее всего, плохой дизайн, да. Так сказать, "красный флаг" - это круговая ссылка. Вы сказали:
... объект задает вопрос другому объекту, который косвенно удерживает его
Итак, объект "удерживающий" имеет ссылку на объект "удерживаемый", а также для того, чтобы "задать вопрос", объекту "удерживаемый" потребуется ссылка на объект "удерживающий".
Это создает круговой граф зависимостей объектов и часто является запахом кода.
Казалось бы, какой-то другой класс должен нести ответственность за знание как о персонаже, так и о TileManager и/или CharacterManager.