ЗАБУДЬТЕ GRASP

Хочу с вами открыть разговор про паттерны проектирования с такого любимого дедами👨‍🦳 набора как GRASP.

📯Это что за покемон?

Во-первых, что, вашу мать, такое этот ваш GRASP🤷‍♀️? Википедия пишет:

— шаблоны ПО для назначения главных ответственностей

, однако это просто неправда🤥!

Чтобы вы составили представление, вот типичные "паттерны" GRASP📜:
– Низкое зацепление⛓️‍💥 – ну это, короче, когда подпрограммы/модули слабо связаны друг с другом.
– Высокая связность🧶 – это когда в одном модуле содержится только то, что непосредственно с ним связано.
– Полиморфизм🐏 – Нет, ну это уже ни в какие ворота...

Ну вы поняли, это больше похоже на жизненные советы от пьяного бати🍷, чем ясные☀️ паттерны, которые вообще хоть что-то означают🤨.

📯Цель была упростить программирование

Я до этого GRASP не смотрел внимательно, а так, издалека посмеивался👉. Но для статьи должен был вникнуть👩‍🎓. И мне пришлось вникать🧐... То есть, вместо 5 минут, я потратил около часа на прочтение нескольких статей📖, выяснил, что каждая о чем-то своем, добрался до первоисточника, и наконец разобрался💡. И результат не то, чтобы стоил усилий.

Там никакой мудрости предков😺, никакого космического озарения🧘, только немного воды💦 и сложносочиненный пятикратно переваренный SOLID😅.

📯О чем на самом деле GRASP

В книге Крейга Лармана «Применение UML и шаблонов проектирования», где они впервые появились, прямым текстом об этом написано🫳:

Что такое шаблоны GRASP?
– Это шаблоны, описывающие фундаментальные принципы распределения обязанностей между объектами.

Уберите отсюда совершенно не к месту использованное слово "шаблоны"🚜, и станет ясно, что хотел сказать автор🤔:

Сейчас я вас научу распихивать отношения между классами на основании их ответственностей.

Если прочитать главу целиком📖, дополнительно откроется, что уважаемый учитель👨‍🏫 пытается объяснить, как так из предметной области🚢 нарисовать красивую UML-диаграмму 🚤, чтобы потом, может быть, это спрограммировать🛳️.

Резюмируя📦, GRASP – список принципов, имеющих довольно узкую сферу применения🤏, и неоправданно сложных для понимания🧐.

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

🤡 – Я репер, я умею только грррясп.
👌 – Нельзя забыть то, чего не знал.

MVVM – ОТДЕЛЯЕМ МОРДУ ОТ ТЕЛА

Обплевав GRASP, давайте теперь поговорим о настоящих паттернах.

📯Model-View-ViewModel

– шаблон, разделяющий программу на три части:
Model – бизнес-логика🏭;
View – графический интерфейс🖼;
ViewModel – мостик между ними🌉.

Таким образом, мы разделяем проект на два независимых друг от друга модуля➗: картинку и данные. А между ними для сообщения кидаем мостик в виде ViewModel⛓.

📯Где его можно использовать?

Да практически в любом приложении с графикой💅. Ведь он позволяет:
Во-первых, работать независимо дизайнерам👨‍🎨 (возможно, даже без кода) и программистам👨‍💻.
Во-вторых, легко перенести часть или всю модель на другую платформу🚉. То-есть, при резком изменении интерфейса программы, нам не придется переделывать ее всю, а только View🧠.

Также этот шаблон позволяет цеплять несколько интерфейсов к одним данным🪝 (заходить Вконтактик с компьютера и телефона): в вебе и мультиплеерных играх🌐 MVVM "включен" по-умолчанию, потому что там сервер⌨️ и морда😐 (бэкенд и фронтенд) выполняются на разных машинах🚗.

📯Расширяем сознание

Конкретно наш паттерн в узком смысле строго привязан📍 к платформам WPF и Silverlight (даже не гуглите, что это), потому что использует их механизм привязки данных🧶. Однако в такой трактовке было бы мало смысла его тут разбирать🤡.

Но стоит заменить "конкретный механизм привязки" на "любой механизм привязки", и дело становится намного интереснее😳. Тогда нам будет безразлично, как именно организован ViewModel: хоть этим самым биндингом, хоть Observer'ом, хоть вручную🫳.

📯Семья MVVM

Вообще-то, придумать, как разделить картинку и данные пытались уже давно👵, и у MVVM есть два (не очень удачных) старших брата👨‍👨‍👦:

1. MVC – Model-View-Controller:
Контроллер изменяет модель, а модель изменяет вид♻️. Такой вот любовный треугольник получается❤️. На мой взгляд, тут два минуса: неполное разделение модели и вида🔪, а также лишнее разделение ввода📥 и вывода📤.

2. MVP – Model-View-Presenter:
Presenter управляет как View, так и Model. Здесь тот же MVVM, но промежуточное звено не просто адаптер, а управляющий элемент👑. Соответственно, Model – превращается в DTO с небольшим количеством логики📦.

⬇️ Пишите в комментариях, какие еще паттерны стоит разобрать! 💬

🤡 – О да, моя программа прямо модель, и у нее такие виды🫦
🎸 – Классы MVC такие:
"Я кондуктор, я кондуктор,
Люди для меня как фрукты"

Помните пост про вайбкодинг🤔?
Теория теорией, но давайте на практике посмотрим, на что способен современный искусственный интеллект🤖: попробуем навайбкодить себе простую игру и посчитаем, сколько критических багов в ней окажется😂!
📱 Конечно, в прямом эфире на твиче 📱,
так что вы можете в этом поучаствовать!

ОСЬ ИЗМЕНЕНИЙ (НА КОТОРОЙ Я ВЕРТЕЛ ВАШ SRP)

Во многих статьях я уже упоминал ее вскользь👀, пришло время поговорить подробнее об этом явлении💬.

📯Ось изменений

– это линия, проходящая через модуль/класс, когда его необходимо затронуть🫴 для внесении того или иного изменения.

Сами изменения могут быть любыми, от исправления багов🪲 до удаления старых🗑 или добавления новых фич🎇.

📯Зачем она нужна?

Если вкратце, то для измерения соответствия SRP📐, но и не только. Ведь если у нас через модуль проходит единственная ось изменений, то у нас есть единственная причина его менять – значит, он имеет только одну ответственность🧠.

На практике, кончено, такого никто добиваться не будет😂. Однако больше 2-3 осей на модуль свидетельствуют о том, что вам лучше встать на кухню, ведь вместо кода получается лапша🍜.

📯В смысле 2-3, написано же SINGLE responsibility?!

Понимаешь ли, дело в том, что всем немного насрать...
На самом деле, есть разница еще в размере класса🤏, а так же в связности этих изменений⛓.

Первое просто: если модуль небольшой и позволяет держать его весь в голове одновременно🤔, можно пока что не думать о его разделении👌.
Второе говорит о вероятности затронуть две оси вместе👋. Например, когда мы меняем способ формирования данных👩‍💻, мы наверняка захотим изменить и их вывод🖼. В большинстве случаев.

Да, MVVM идет в жопу с таким подходом, однако.. а оно нам правда всегда нужно🤔? Как итог, я никогда не разделяю логику счета каких-то мелочей и их отрисовку🤟.

📯Не плодите классы

Давайте немного изменим определение:

Ось изменений – это линия, проходящая через модули/классы, которые необходимо затронуть🫴 для внесении того или иного изменения.

Таким образом, как шашлык на шампур🍢 мы насаживаем всех, кто касается нашего обновления🆕. И их тоже не должно быть слишком много. Иначе ты очень скоро запутаешься, что на чем завязано🧐, и сам утонешь в своем же болоте🐸.

🤡 – В моем коде нет лишних ответственностей, потому что я писал его безответственно😂.
👌 – В мой код не нужно вносить изменения, он и так идеален!

КАК Я ПОБЕДИЛ БЕЛЫЙ ЛИСТ

Страх белого/чистого листа – распространенное явление. Это состояние, когда решил начать новый проект, но.. с чего начать-то🤔..?

📯Ножницы бьют бумагу

Суефа дает важную подсказку: лист надо разрезать✂️. Иначе говоря, слона надо есть по частям🐘. В общем, разбей задачу на подзадачи, эти подзадачи на еще более мелкие подзадачи, и так пока не достигнешь размера в 5-10 минут👊. Короткое и простое дело легче начать, но главное – ты будешь знать, что делать👍.

Имея список📜 (а лучше – план🚫) действий, ты убьешь сразу двух зайцев🐇:
Во-первых, в маленькой задаче глаза не разбегаются👀;
Во-вторых, само написание плана действий – уже действие✍️.

📯Возьми этот лист и подотрись им

Во многом страх начать новое продиктован ответственностью, возлагаемой первым заложенным кирпичиком🧱. Ведь от того, как начнешь, зависит ход всего проекта🏃! А что, если ты накосячишь в самом начале, и это аукнется так, что потом придется все переделывать😨?

Как хорошо, что все это не правда🙅‍♂️. Мы не запускаем марсоходы, наши ошибки не стоят миллиарды долларов🪐. Но что самое важное, наши ошибки стоят намного меньше, чем промедление🐢 в стремительном потоке рынка🤑. К тому же, вероятность провалить проект из-за плохой идеи намного выше, чем вероятность провалить проект из-за каких угодно ошибок на старте🩼.

Почти все в ИТ сделано через жопу, и ничего, работает💩! Вот и ты снимай белые перчатки, засучай рукава, и начинай работать👨‍💻. В конце концов, ошибки – это ценнейший ресурс – опыт😎, который как раз и нужен для (зачаровывания инструментов📚💎) успешного проекта😁!

📯Аппетит приходит во время еды

Создай проект📱, настрой гит📱, создай беседу в тг📱 или другом настоящем мессенджере для работы📱, если у тебя команда. В общем, сделай вид, что ты уже начал проект🤥.

Подсознание обмануть не так сложно, оно сформировано для управления доисторической ящерицей🦖, которая в разы тупее курицы🐔.

📯Прекрати прокрастинировать

Подробнее я напишу об этом в отдельной статье, здесь только скажу, что в белой пустой комнате📝 проекты начинаются намного проще, чем за компьютером с Майнкрафтом🦥.

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

👌 – Следую только второму совету, на этом мои новые проекты и заканчиваются...
🤡 – Страх белого листа сформировался из-за многолетнего систематического угнетения ими черных листов.

Давно меня не было в уличных гонках🏎...
Но все хорошее когда-то заканчивается, так и мое отсутствие в этом паблике🤷‍♀️. Да-да, вы не ослышались, снова буду душнить про код и около него🎉!!!
А пока вы ждете новый пост⏰, посмотрите, как я делаю новую прикольную игру в прямом эфире👀!
📱 Уже начали, присоединяйся! 📱

ИГРОВАРЕНЬЕ ДЛЯ ЧАЙНИКОВ

📯Что это?

Game jam – мероприятие, где разработчики пытаются с нуля выстругать игру на предложенную тему👨‍💻. Игровары работают соло, либо в небольшой группе🫂. Длится этот шабаш от одного до четырех дней🗓.

Это, конечно, в среднем, а вообще каждый пункт из определения выше может быть неправдой🤷‍♂️. Геймджемы все уникальные, каждый со своими правилами и особенностями🤩.

📯Сначала поговорим о награде

Иногда есть денежный приз💰, но, на самом деле, лучше, когда без него👹. Деньги там смешные, зато вместо здоровой конкуренции будут накрутки, обиды и истерики😡. Так что за деньги – нет🙅‍♂️.

По-настоящему ценной наградой геймджема являются опыт и респект😂. И да, в нашей ситуации, деньги действительно не главное😐.

📯Ахаха, может, мне еще и GNU-лицензией игру подписать?

Да, понимаю, делать что-то бесплатно – триггер всех работников интеллектуального труда😡. Но что, если я скажу вам, что это не бесплатная работа, а обучение на реальных кейсах в условиях рынка🛒, да еще и не за 180 000₽ (привет, GeekBrains🤓), а бесплатно😁? Глазки уже заблестели, отсюда вижу😎!

А еще не стоит забывать про нетворкинг🔗! И, хотя комьюнити там довольно специфическое🤪, и мало связанное с деньгами🍟, но ребята преинтересные и опытные🧠! Многих сам люблю слушать, и не стыдно🤓.

📯Бесплатный плейтест

Придумал прорывную идею, но как узнать, понравится ли она публике🤮? Приноси ее на геймджем🍰!

Тут за три дня ты склепаешь MVP, в которую точно поиграют люди👾! Это может сэкономить тебе годы(!) работы над проектом💩!

А организаторы приведут народ🤪, да еще и заинтересованный поиграть в разные игры🤓, в т.ч. и в твою. Звучит даже как-то незаконно🔐...

📯Кому туда не надо

Если ты разработчик, и хочешь быть разработчиком🚣, а не человеком-оркестром🪗, то на геймджемы тебе путь заказан❌. Больше всего очков опыта там дают в ветке геймдизайнерства🖥, далее работа в команде😭 (если она есть), а вот программирование/рисование/другой спец. скилл – совсем чуть-чуть🤏. Потому что если ты в трехдневном проекте начнешь соблюдать SOLID🏗, то к концу джема у тебя будет очень красивый рисунок ключика.🏴‍☠️. А игры не будет. Делай монолит, и не выпендривайся👊.

Также не надо туда идти, если ты хочешь побыстрее запрыгнуть на галерку🚣. Геймджемы – путь к открытию собственной студии🔞, а это значит жить на бабкину пенсию первые 3-5 лет👵, и то, если повезет🤞. То есть, конечно, если ты возьмешь проект с джема и допилишь его, хуже не будет, но первому проекту совсем не нужен джем👍.

🤡 – Мое любимое игроваренье – с клубничкой😏
👌 – Берем сперва укропу, потом кошачью жопу... Вот и получился проект на джем!