Разработчик игр, интерактивных стендов и интерактивной рекламы. Эксперт в области интерактивов и XR.
100+ проектов за 5 лет. https://whitelabelgames.ru
По вопросам сотрудничества писать: @it_bizdev
Post #685
1.05K
Решение «Проектируем гриды»
Мне не нравится, как выглядят огромные спойлеры. Поэтому если хотите подумать сами, сначала сами и не видели задачку — не читайте дальше. А теперь к решению.
Сразу скажу. Тут нет «единственного верного решения». Если решение обосновано и чётко, то вероятно и оно окей. Но я хочу поговорить с точки зрения моей идеологии в таких случаях.
DRY прекрасный концепт. И эта задача появилась из размышлений на тему этой концепции. Но я считаю, что он не всегда нужен. И поговорим о сущностях, а точнее даже о логике доменов. Я бы сделал две совершенно не связанные системы. Да, возможно там было бы дублирование, но это неважно из-за того, какие преимущества даёт нравящийся мне подход и понятие под названием — разные домены.
Почему это две не связанные системы? Потому что это разные сущности и разные домены. Не должно из-за изменений логики игры ломаться поведение интерфейсов. Это должны быть две независимые системы, чтобы изменения влияли только на этот домен. И даже в Unity это сделано так. Но пойдём по порядку.
Вариант 1. Общий класс. Самое опасное решение ведущее к проблемам в разработке и костылям, можно сразу откинуть. Этот вариант не особо рабочий. Так можно сделать если вам нужно написать за 5 минут, сдать и забыть. Но в среднем — это худшее решение.
Вариант 2. И вариант 4. Общий базовый класс и наследование. Чуть лучше, но тоже вызывает вопросы, а зачем вам такая абстракция. С общим базовым классом в том, что вынесено в него ведёт к рискам обозначенным выше. Вы правите какой-то баг грида в гуе, вы его исправили, и у вас вылезла проблема в игре. Такого происходить не должно. Общий интерфейс. А для чего? Какой контекст применения и использования такого интерфейса? Вы когда-то будете его юзать в рантайме? Я не вижу особой проблемы в композиции. Но при развитии системы могут появится сложные системы интерфейсов или компромиссы нарушающие солид (второе просто ошибка). То есть не реализованные методы интерфейса в одной из частей. Это усложнение системы, да убирающее дублирование, но не дающее никакой супер функиональности. Это не та система, где сложные алгоритмами и спустя год вы будете менять в двух местах реализацию, что гемморой. Если появятся разные виды гридов в рамках одного домена, я бы пошёл по пути интерфейса. А в разных я бы делал так.
Я бы делал так же, как и сделали юнити. Так как в юнити у вас есть и грид для 2д игр, и грид лейаут груп. И они никак не связаны. Это даёт нам разрабатывать системы с «похожим поведением» из разных доменов независимыми. Не сидеть и думать и долго проектировать «какая тут правильная композиция». А просто писать две разные системы, потому что они находятся в разных доменах приложения. И удобнее их разрабатывать независимо. Там нет каких-то сложных алгоритмов, которые нужно обобщать. Но если и выносить именно алгоритмы, то в отдельный статик класс, который будет в домене части системы, которая отвечает за алгоритмы. Типа для примера ту же сортировку вы не будете писать каждый раз. У вас будет генерик реализация самого алгоритма.
#задачка
Мне не нравится, как выглядят огромные спойлеры. Поэтому если хотите подумать сами, сначала сами и не видели задачку — не читайте дальше. А теперь к решению.
Сразу скажу. Тут нет «единственного верного решения». Если решение обосновано и чётко, то вероятно и оно окей. Но я хочу поговорить с точки зрения моей идеологии в таких случаях.
DRY прекрасный концепт. И эта задача появилась из размышлений на тему этой концепции. Но я считаю, что он не всегда нужен. И поговорим о сущностях, а точнее даже о логике доменов. Я бы сделал две совершенно не связанные системы. Да, возможно там было бы дублирование, но это неважно из-за того, какие преимущества даёт нравящийся мне подход и понятие под названием — разные домены.
Почему это две не связанные системы? Потому что это разные сущности и разные домены. Не должно из-за изменений логики игры ломаться поведение интерфейсов. Это должны быть две независимые системы, чтобы изменения влияли только на этот домен. И даже в Unity это сделано так. Но пойдём по порядку.
Вариант 1. Общий класс. Самое опасное решение ведущее к проблемам в разработке и костылям, можно сразу откинуть. Этот вариант не особо рабочий. Так можно сделать если вам нужно написать за 5 минут, сдать и забыть. Но в среднем — это худшее решение.
Вариант 2. И вариант 4. Общий базовый класс и наследование. Чуть лучше, но тоже вызывает вопросы, а зачем вам такая абстракция. С общим базовым классом в том, что вынесено в него ведёт к рискам обозначенным выше. Вы правите какой-то баг грида в гуе, вы его исправили, и у вас вылезла проблема в игре. Такого происходить не должно. Общий интерфейс. А для чего? Какой контекст применения и использования такого интерфейса? Вы когда-то будете его юзать в рантайме? Я не вижу особой проблемы в композиции. Но при развитии системы могут появится сложные системы интерфейсов или компромиссы нарушающие солид (второе просто ошибка). То есть не реализованные методы интерфейса в одной из частей. Это усложнение системы, да убирающее дублирование, но не дающее никакой супер функиональности. Это не та система, где сложные алгоритмами и спустя год вы будете менять в двух местах реализацию, что гемморой. Если появятся разные виды гридов в рамках одного домена, я бы пошёл по пути интерфейса. А в разных я бы делал так.
Я бы делал так же, как и сделали юнити. Так как в юнити у вас есть и грид для 2д игр, и грид лейаут груп. И они никак не связаны. Это даёт нам разрабатывать системы с «похожим поведением» из разных доменов независимыми. Не сидеть и думать и долго проектировать «какая тут правильная композиция». А просто писать две разные системы, потому что они находятся в разных доменах приложения. И удобнее их разрабатывать независимо. Там нет каких-то сложных алгоритмов, которые нужно обобщать. Но если и выносить именно алгоритмы, то в отдельный статик класс, который будет в домене части системы, которая отвечает за алгоритмы. Типа для примера ту же сортировку вы не будете писать каждый раз. У вас будет генерик реализация самого алгоритма.
#задачка
- 👍 8
