Всем привет, разбирался и все еще пытаюсь разбираться в паттернах, в теории там все понятно, однако на практике оказывается что не всегда код по паттерну является оптимальным. К примеру, делаешь игру на PC от 1 лица которая будет сюжеткой и без обновлении, стоит ли вообще к такой игре применять паттерн? и если да, то какой? mvvm сразу же стоит отбросить как мне кажется, т.к. он нужен только там, где есть куча UI который возможно будет меняться.
Даже если ты не будешь специально обращать внимание на паттерны, сам то чего-то подобного дойдешь, лет за 5-10 практики. Паттерны просто позволяют быстрее выйти на профессиональный уровень, предлагая хорошие решения, до которых ты возможно сам бы дошел не скоро. Рассматривай их как продолжение структурного программирования. Порядок в программе - это всегда хорошо.
Однако, ничто не мешает изобретать свои порядки. Но лучше бы их изобретать отталкиваясь от существующих. И с другими коммуницировать будет проще, и граблей избежишь, на которые понаступали уже твои предшественники.
У меня с паттернами были сложные отношения. Такое понятие появилось, когда я уже давно и успешно программировал, уже сам все нужное изобрел и подсмотрел. Вроде как, они и не нужны, опоздали, но случались всякие непонимания с теми, кто учился по паттернам.
Zab
т.е. можно легко с ними экспериментировать, а не пытаться делать все лишь по предусмотренному паттерну? Спасибо за развернутый и полезный ответ!
dengeatz
бросай это безнадёжное дело, в юнити самый важный паттерн Game Loop скрыт от глаз, тебе выдают лишь Update() или FixedUpdate()
вот список кстати если речь про игры
https://gameprogrammingpatterns.com/contents.html
Паттерны могут быть на разных уровнях абстракций. Не заморачивайся сразу с ними. Лучше столкнуться с задачами, а потом почитать теорию еще раз, тогда понятнее будет о чем речь и где и как можно применить.
Когда у меня было сильно меньше опыта, чем сейчас, я тоже такие странные вопросы задавал.
Паттерны можно почитать, но без практических итераций от этого толку мало будет. Делайте как получается, старайтесь найти место для применения теории.
dengeatz
> К примеру, делаешь игру на PC от 1 лица которая будет сюжеткой и без обновлении
1. StateMachine - Для управления состояниями персонажей и врагов
2. Singleton - основные игровые системы, которые должны быть в одном экземпляре(Вввод, сохранение, настройки и тд)
3. MV*-паттерн(любой) для UI
4. Observer Pattern/Event Bus - для событий внутри игры.
5. Factory Pattern - создание объектов и игровых сущностей
6. FlyWeight - SO для общих данных сущностей
7. ServiceLocator(опционально) - управление зависимостями
8. ObjectPool - для прожектайлов, если такие планируются, да и вообще для любых создаваемых часто и на короткое время объектов
9. Strategy - спавнеры с различной логикой
10. Mediator - для соединения различных систем
И т.д и тп. Я уверен, что еще целую кучу можно применить при желании.
Increaser
Спасибо! А есть смысл использовать MVx паттерны не на UI?
dengeatz
> А есть смысл использовать MVx паттерны не на UI?
С моей точки зрения - нет. Однако я встречал целые компании, в которых все выстроено вокруг MV*-паттернов.
Ты можешь попробовать и решить, подходит оно к тебе или нет. Если проект личный, то вообще никто не мешает пробовать любой подход.
Задача паттернов облегчить разработку и помочь командам выработать общий подход к решению типовых проблем. "Паттерн ради паттерна" всегда не самый лучший подход.
Паттерны, как таковые не особо нужны. Только Фабрика и Билдер (создавать объекты) и Обзервер (коммуникации между компонентами). В 90% случаев ты напихиваешь std::vector уник_птр-ами и инитишь листенеры на апдейт или какие-нужные еще вещи. А дальше только SOLID.
И еще важно знать, как выжимать мс из данных.
Тема в архиве.