КАК ПРАВИЛЬНО шКОДИТЬ, ЧТОБЫ ПРЕДКИ УЛЫБАЛИСЬ ТЕБЕ

Вот ты выучил язык программирования👅, начинаешь вливаться в комьюнити, а все вокруг только и говорят про какие-то паттерны и принципы программирования🧐. Давайте разбираться.

📯Паттерны

Шаблон проектирования – повторяемая архитектурная конструкция для решения типовой проблемы.

Например, часто возникает задача уведомления объекта🔔 об изменении в другом объекте. И мы не чешем репу🤔, как изобрести такую штуку с сиденьем и двумя колесами, а пишем Observer🔭. Разумеется, немного подпилив под себя.

В целом, это крепкие, дедами отполированные, сердитые решения💪, годные и для твоей поделки на коленке, и для жирнющего энтерпрайза. Плюс, знание паттернов позволяет в двух словах объяснить довольно сложную систему взаимодействия объектов🗑.

Есть еще Антипаттерны💩 (Монолит🗿, например) – тест на вшивость, если узнал себя, то пишешь говно – и ненастоящие паттерны (Например, АбСтРаКтНаЯ фабрика🤮) – впариваемые инфоцыганами, чтобы сделать "ТОП-88 Паттернов проектирования". И есть еще GRASP, которые придумали древние шизы🍄, и они должны быть утеряны в анналах истории🗿...

📯Принципы

Это заповеди, выбитые на скрижалях Всеотцами программирования😀 типа Боба Мартина. Самые популярные из них: SOLID🔗, KISS💋, DRY👣...

Их надо соблюдать, но не до конца🤫, потому что части из разных наборов противоречат друг другу, иногда – части из одного набора противоречат друг другу, а, доведенные до крайности, некоторые принципы противоречат даже сами себе💊...

Но, в остальном, это звучит как "не клади все яйца в одну корзину"👌 или "береженного Бог бережет"😇 – чисто житейская мудрость пращуров, добытая горьким опытом✝️.

Стоит следовать им на крепкую четверку4️⃣, не больше, а со временем они сами впитаются в голову🧠.

❤️ – Подробный разбор паттернов
🔥 – Подробный разбор SOLID

ОБОЗНАЧЕНИЯ КРУПНОЙ О (BIG O NOTATION)

Когда мы только начинаем вырастать над уровнем "написать Hello, world!"👋, пора начинать задумываться над эффективностью алгоритмов🤔. Но как ее оценить, если время выполнения зависит от многих факторов, не связанных с кодом: от компьютера, от параллельно запущенных программ, от использованного языка?🤔

Здесь нам на помощь🆘 приходит
📯Нотация Big O

– способ измерения эффективности алгоритма с циклом или рекурсией🔁, привязанный только к количеству входных данных🔠. Применяется она к двум параметрам: времени и памяти.

Простая проходка🚶‍♂️ по коллекции будет O(n), и рост времени тут в линейной зависимости от количества элементов в массиве (x2 элементов = x2 времени)📐 . А вот если засунуть эту проходку в еще один цикл, то будет уже O(n²). (Примеры на коде в описании). Это квадратичная функция🟥, это плохо, такого мы стараемся избегать.👎

Таким образом, Big O позволяет нам определить, насколько сильно наш алгоритм поперхнется😮‍💨, если мы всунем в него огромный поток ценных данных📊. А это очень полезная информация, если мы планируем масштабировать систему🤯.

📯Как этим пользоваться

Берем наш цикл и вытаскиваем из него количество итераций🔃. Обозначаем их как n. Затем избавляемся от всех констант🗑.

Так, O(2n - 1) легким движением руки🧙‍♀️ превращается в O(n). Вы можете возмутиться, мол, как же так, ведь два цикла - больше, чем один цикл😱!!!

А я вам скажу, что, если у вас два цикла отличаются от одного только количеством, то либо второй цикл ничего не делает, либо вы пизпривираете🤥. Ведь, чтобы получить тот же вывод, сама итерация изменилась🧠.

То есть, сравнивать жопу с пальцем смысла нет, уяснили🧠? Но что мы можем сравнить - так это то, что в обоих случаях при х2 данных будет х2 времени. Значит, по Big O два эти алгоритма одинаковые.🪞 Смиритесь.

📯Зачем этим пользоваться?

С помощью Big O можно легко оценить, насколько алгоритм говно💩
Например, пузырьковая сортировка будет O(n²) – это в n раз хуже допустимого🤡

То есть, теперь у нас появилась линейка, которой мы можем померить кривизну рук разработчика, очень удобно👍

😱 – У меня от пляжных кружочков до сих пор на лице Big O
🤓 – Да кому нужны эти метрики, если и так сойдет?)))

За примерами на коде в комменты⬇️

МЯГКИЕ СПОСОБНОСТИ (СОФТ СКИЛЛЫ)

📯Программирование больше не тайное учение

Давно прошло то золотое🌧 время, когда программистами могли стать только суровые задроты🤓 в вонючих свитерах с оленями🦌. Эпоха гениев, не тронутых женщиной, закончилась👁.

Во-первых, порог входа пробил днище. Теперь не нужно дрючить байтики, а можно клепать No-Code говнище💩, и все равно будет работать. И, что самое страшное, будет работать хорошо👍. По крайней мере достаточно хорошо, чтобы брать за это деньги🤑.

Раньше, чтобы написать игру, тебе нужно было досконально знать устройство компьютера👩‍💻, изобрести собственный движок, отрисовывать каждый кадр, а затем все это уместить в 12 бит памяти мощнейшего компьютера того времени🩴. И все это за респект, потому что компьютеры есть только в универах и в ЦУПе🛰. Разумеется, таким будут заниматься только отбросившие все человеческое👀.

📯Для чего тебе может понадобится говорить с людьми

Во-первых, любое современное ПО делается в кооперации🫶🫶.

Для того, чтобы сделать что-то качественное, тебе нужен художник, звукарь, программист, сценарист, гейм-дизайнер, тестировщик👨‍🎨🎧🧑‍💻✍️👎... Допустим, часть из этих ролей совмещается, но чем их больше в одном индюке🦃, тем хуже качество исполнения каждой. А уж если мы говорим, о чем-то большем, чем инди-поделка, то любой коллектив среднячков >> один гений🧙‍♀️.

Во-вторых, тебе понадобится продавать себя и свои продукты💵.

Навыки общения помогут тебе как договориться на более высокую зарплату, так и продать стартап толстосуму-инвестору🤑.

Представь, что ты супер-крутой мега-программист🌚. Как об этом узнает весь мир, если ты двух слов связать не можешь🤔? То-то и оно...

📯Ну вот я интроверт, не люблю общаться с людьми, что мне теперь делать?

Я тоже. А вот, работаю с людьми. Хотя лет шесть назад до слез боялся позвонить по телефону😭. Кстати, это правда.

Да и никто не говорит, что надо любить общаться с людьми. Надо уметь👍. Сомневаюсь, что есть люди, которые обожают ездить в автобусе или убирать квартиру. Может, найдутся любители платить налоги? Но это все мы терпим🫡.

Помните, что кринж мертв🤦‍♂️, любой позор переживаем, и ничего катастрофического не будет, если вы скажете что-то не то🥴. В рамках УК РФ, разумеется...

Если совсем никак, попробуйте обратиться к психологу💉 – эта темка реально многих захилила💊.

_____________________________________

И выйди уже из комнаты,
Соверши уже, блять, ошибку!
Солнце не будет лишним,
Если ты куришь шибко.

_____________________________________


🪕 – Мама, пожалуйста, не надо крика!
Просто я хикка, просто я хикка...
😱 – ААААААА, ЖЕНЩИНА!!!!!!!

SOLIDное программирование #1

Вы захотели принципов🤩 (так было решено здесь). А значит, теперь мы подробнее рассмотрим шесть самых попсовых правил, из-за которых все срутся в интернете👊.

Оглавление:
S – Single Responsibility 📍
O – Open-Closed
L – Liskov Substitution
I – Interface Segregation
D – Dependency Inversion
(Bonus) DRY – Don`t repeat yourself

📯S – Single Responsibility Principle

– каждый объект должен иметь одну ответственность☝️, и эта ответственность должна быть полностью инкапсулирована в класс📦. Я дальше буду говорить про классы, но то же самое относится и к методам✅.

На мой взгляд, самый ясный☀️ из принципов. По-простому, ответственность – это то, за что отвечает данный класс😱. То есть, никаких побочных квестов, никаких дополнительных функций у класса не должно быть, кроме его главного предназначения⚔️.

Пример:
Вот у нас есть радио с часами📻⏰. Неправильно будет запихнуть обе этих ответственности в один класс. А нужно либо класс Часы⏰ положить в класс Радио📻, либо создать два равноважных класса.

📯Зачем?

Во-первых, тогда Ось изменений🔄 – линия, пронзающая🏹 все классы, которые придется затронуть при необходимости некоторых изменений (в том числе, исправлений❤️‍🩹) – будет затрагивать неSRP-класс в меньшем количестве случаев↘️. А, помятуя о священном правиле "Работает – не трогай😇", мы хотим, чтобы эта Ось затрагивала как можно меньше классов.
Во-вторых, если нам понадобится сделать Радио📻 без Часов⏰, мы сможем поступить в соответствии с DRY – взять тот же класс Радио📻, а не писать новый, и не использовать Радио С Часами📻⏰, игнорируя половину его функционала.

📯Окей, тогда отдельный класс под каждый метод – не прогадаешь?

Так же, как мы ограничили максимальное🤚 число ответственностей на класс, мы также должны ограничить максимальное число классов на ответственность🤤.

Это значит, что мы не размазываем ответственность по всему коду, а концентрируем ее в одном классе👍.

Пример:
Вот у нас есть Отчет📎. Будем ли мы хранить в разных классах его заголовок, комментарий и данные🫠? Нет (вдруг правда не знаете🤷‍♀️).

_____________________________________

Напоследок, подсказка💡: если вам хочется в названии класса поставить With/And – это звоночек📞

🪕 – Про ответственность я знаю только, то как ее перекладывать😁
🔥 – Поскорее бы вторую часть🤤🤤🤤

Ура, товарищи!!!!🎉🎉
Сегодня на стриме я смог заставить кого-то чему-то научиться!!!🧠🤓
Хоть и пришлось упростить систему до 1.5 нейронов, зато работает же!🤓
Это значит, что мои попытки вкатиться в нейросети не безнадежны✅
Через недельку будем писать красивый вывод в инспекторе, а завтра утром напишу, что произошло за ночь.

За ночь почти ничего не произошло🦕. Видимо, условия меняются слишком стремительно во время игры🔜. Но это лишь значит, что сетка уже через час была идеальной😎
А если у вас остались вопросы, или просто хотите пообщаться, то заходите на Майнкрафт🌎 прямо сейчас!!!
Будем дальше строить метро, болтать и обсуждать вчерашние новости📰

P.S. Кстати, на гите этот проект уже лежит и обновляется после каждого стрима ;}

(НЕ) ПИШЕМ КОД ЖЕСТКО

📯Что значит "Жесткий код"?

Хардкод - такой, в котором данные вписаны непосредственно в исходник.

При таком подходе в нашей программе неизбежно появляются "магические числа"🔮 (или строки, или любые другие типы) - данные, которые вписаны в код просто потому что вот сейчас вот здесь они подходят😕.

📯Почему мы это делаем

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

Это не хороший код, но достаточно хороший, чтобы вывезти. А этого, как известно, часто хватает💩.

📯Последствия

Конечно, если бы хардкодить можно было без кашля и болей в мышцах, этой статьи бы не было🧠.

Во-первых, вписывая данные непосредственно в код, мы смешиваем бизнесовую логику с программной🔵.

Про важность слоев абстракции в коде я как-нибудь расскажу подробнее🤥, а пока представьте, что для обновления цены на товары нужно обновлять приложение Домино'с🤪...

Во-вторых, система, написанная жестким кодом слишком.. жесткая. Как бы это странно не звучало...🤔

Такая система заточена только под определенные сценарии работы и не может быть адаптивной по определению🙅‍♂️. Тут не то, что маловероятная череда совпадений – неожиданный размер экрана заставит программу поехать🤭. В некоторых случаях – кукухой🦆. А уж если заменить какой-нибудь спрайт, не сохраняя размер😶...
Это как вставить таблицу в Ворде – придется менять размеры и положения вообще всего в программе📉.

В-третьих, хардкодинг осложняет рефакторинг до невозможности☝️.

Увидев строку
4.189 * Math.Pow(R, 3)
, вы вряд ли сразу поймете, что это всего лишь площадь шара🎱.
А вот
4 / 3 * Math.PI * Math.Pow(R, 3)
дает как примерное представление о том, что происходит, так и описание формулы по первой ссылке🌐.

📯Окей, тогда код должен мягким (и пушистым🐈)

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

В крайней форме, у нас нет ни одной цифры или строчки в коде, они все либо подтягиваются из окружения🧹, либо вводятся пользователем⌨️. Это, разумеется, тоже черевато: наш код превращается в лапшу🍜, вытекает сквозь пальцы🫠, в нем формируется примерно миллиард зависимостей🔗 всего от всего, и поддерживать это невозможно🙅‍♂️.

📯Что делать?

Совет от Вероники Степановой🧘:
Код должен быть как хорошая какашечка💩: не слишком твердый, а то мы порвем себе узкие места, но и не слишком жидким, а то, как не напрягайся, все равно где-то да потечет...

А в благодарность🥰 тем, кто дочитал до конца я объявлю три простых правила📚, которые позволят определить, как жить правильно😇:

1. Это бизнес-логика💼?
– Если да, то запиши в константу и, по ситуации, напиши комментарий📝.

2. Это связано с окружением👁? (размер экрана, имя пользователя, время суток и т.д.)
– Выведи формулу и привяжи к окружению, т.к. оно точно поменяется рано или поздно🏎.

3. По контексту кристально ясно☀️, для чего здесь эта цифра (если мы начали читать с куска с хардкодом), и где искать эту цифру🔍 (если нам нужно изменить логику, которую мы захардкодили ранее)?
– Можешь оставить так, пофигу, есть более важные дела👍.

🪕 – Можно быть нежным до и после, но когда пишешь код – жестким, будто забиваешь гвозди в ее доме!

SOLIDное программирование #2

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

Оглавление:
S – Single Responsibility
O – Open-Closed 📍
L – Liskov Substitution
I – Interface Segregation
D – Dependency Inversion
(Bonus) DRY – Don`t repeat yourself

📯O – Open-Closed Principle

– программные сущности в виде гномика (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения.
Этот принцип говорит, скорее, о том, как мы подходим к разработке, а не о том, какие классы мы разрабатываем.

А теперь, что это значит:
> Открыты для расширения – поведение сущности может быть расширено путём создания новых типов сущностей➕.
> Закрыты для изменения – в результате расширения поведения сущности, не должны вноситься изменения в код, который эту сущность использует🙅‍♂️.

В жестком варианте это полный запрет на любые изменения кода⛔. Если понадобилось что-то добавить или изменить – наследуйся от существующего🤱. Слава Богу✝, принципиальщики не запрещают исправление багов, а то, формально, это тоже против OCP🤦‍♂️...
В мягком – нам позволено менять код, но только так, чтобы весь остальной код не пришлось менять вместе с ним🙄.

Тут опять прослеживается "Работает – не трогай😇", но уже как прямое указание. Причем настолько категоричное, насколько это вообще возможно. С ножом у горла🔪.

📯Зачем?

Вообще-то, мысль, конечно, здравая: мы ничего не сломаем, если не влезем своими немытыми руками👋... И в реальном мире действительно проще, чем хотелось бы, уронить огромную систему небольшим изменением😬. Да и не придется тестировать систему заново, если она никак не изменилась🧠.

📯НО

Кто виноват мы выяснили, а как насчет второго главного русского вопроса🇷🇺: Что делать? И тут начинают возникать проблемы😐.

Потому что OCP вместо решения предлагает наплодить кучу сущностей (= натыкать костылей🩼) и сидеть капать слюнями на рубашку🤤.

То есть, да, это может сработать, если у вас доисторическое легаси📖 в огромной куче энтерпрайза🏢. И если при этом наши предшественники-птерозавры🐔 были по семь пядей во лбу🧠, и спроектировали систему так, чтобы при безобидном расширении наследниками она не посыпалась🤪. Только тогда OCP будет работать✍️.

В реальном же мире🌎 нам часто требуется рефакторинг🔨, код, который есть сейчас слишком говно💩, чтобы его охранять, системы не такого масштаба, чтобы можно было случайно уронить все📉, да и при соблюдении остальных принципов, код достаточно легко читаемый📖, и мы можем просчитать последствия своих действий🧮.

Подводя итог, OCP имеет очень узкую сферу применения🤏. Здравое зерно🌾, конечно, есть, но получилось как с коммунизмом🚩: идея отличная, но все попытки реализовать – полная жопа🍑.

🍾 – открываем шампанское, новый пост про SOLID🥂🥂
🤡 – Вот это ты, конечно, открыл Америку🤣

ОТЧЕТ ПО НЕЙРОСЕТИ СО СТРИМА #5

Для начала, вкратце напомню, что изменилось за прошлый стрим🆕:

📯Добавил новый вид препятствия: летающие ящеры🐥.

Проблем они вообще не доставили. Сетка обучилась за пару поколений по-разному реагировать на разные препятствия🏃‍♂️.

📯Динозавры научились смотреть скорость игры🔜.

Благодаря этому прошлый рекорд был побит, да еще как! В 3.5 раза🎉🏆!!! И, теоретически, теперь они могли бы вообще не останавливаться♾️, но тут вступают в дело проблемы с алгоритмом обучения. Расскажу о них ниже👇.

📯Починил наконец-то сам класс нейронки, которая не работала с первого стрима🤢.

Если что, до этого я руками в динозаврике умножал вес на расстояние🫳. Это, конечно, работало, но это невозможно было масштабировать. То есть, первые два пункта уперлись бы в стену очень быстро🧱. Для понимания, сейчас структура сети такая:

3 входных нейрона + 1 смещения
Скрытый слой на 3 нейрона + 1 смещения
2 выходных нейрона.
Всего 20 весов.

Управлять этим вручную – удовольствие ниже среднего🥵. А расширять такую систему – вообще повеситься можно🪑 (не надо).
А сейчас можно легким движением руки добавлять любое количество слоев➕. Просто чудо🪄!

А теперь о плохом точках роста📈:

📯Генетический алгоритм реализован из рук вон плохо🚸.

Динозаврики обновляют рекорд, а затем долго не могут к нему вернуться. Все из-за большого шага мутации🧬 и, возможно, чего-то еще, что я пока не предусмотрел.

📯Также они обучаются медленно из-за непомерно большой длинны поколений👨‍🦳.

Чтобы добежать до 3 000 очков (половина максимального счета), требуется где-то полчаса реального времени🕖. Это около 1/20 всего времени прогона. В итоге, всего за 10⏳ часов прошло 47 поколений. Это очень мало для обучения чему-либо, даже такой простой игре👎.

На следующем стриме попытаемся разобраться в генетическом алгоритме🧑‍💻, а также, возможно, засунем нейросеть в новую игру, которую там же и напишем🕹!

Хочется попробовать какую-нибудь пошаговую тактику или даже стратегию🗺, но для этого надо будет прикручивать сетке память, так что, думаю, пока ограничимся аркадами🕹️.

А вы пишите свои идеи для новой игры в комментариях⬇️

P.S. Потрогать проект своими руками можно на гите!

ВАЙБ-КОДИНГ ИЛИ ПОЧЕМУ ИИ НЕ СДЕЛАЕТ ИГРУ МЕЧТЫ ЗА ВАС

Когда-то давно я пояснял за уровни языков программирования и упомянул там, что т.н. Zero-coding0️⃣ – мертворожденное направление💀. И вот недавно всплыла💩 очередная вершина человеческой лени и жадности – ✨Vibe coding✨. Так что давайте и хайпанем немножечко📣, и заодно разберемся, почему программистов не заменят нейросети🤖 (по крайней мере, пока😐).

📯Большая часть облегчения работы идет за счет обобщений.

Разной степени допустимости😑. Результат закономерно получается менее адаптивным🏚 (хуже подстраивается под конкретные задачи) и менее оптимизированным🐢.

Scratch или GameMaker Studio, или Godot в их блоковых версиях подходят для приобщения дошколят к разработке🚼. Ну, для поделок на 1.5-часовой джем🍼. Но не для серьезных проектов.

Ты буквально потратишь больше усилий на попытки навставлять патчей🩹 и костылей🩼, добиваясь от движка нормальной работы, чем сэкономишь на изучении нормальных языков🚲.

З.Ы. если меня читают Годотеры, то соболезную я вас тоже люблю. Просто особенной любовью. Как прикольных котят🐈.
На самом деле хотел сказать, что верхний текст относится почти полностью к drag-n-drop📲 вариантам, сами движки вполне подходят для джемов и прочих индюшек🦃.

📯Когда уже наступит коммунизм, и работать будут только роботы?

Извините, дорогие мои, но не скоро, на наш век работы хватит😭.

И хотя Иван Иванычи👨‍🎨 уже способны выдавать почти осмысленные и почти работающие куски кода, вот это "почти" – те самые 10% результата, требующие 90% работы🥵.

ИИ способен немного облегчить жизнь программисту👨‍💻, с его помощью можно написать лабу в универе🔨, но не более. А для получения какого-то осмысленного продукта за нейросетью нужен постоянный пригляд со стороны настоящего разработчика👁‍🗨.

Причина же кроется в том, как работают языковые😛 модели: если вкратце, они пытаются угадать, какие слова в ответе на запрос пользователя будут "красивее"🥹 смотреться. И для задач типа "Перепиши письмо в деловом стиле💼" это как раз то, что нужно, но не для кода👩‍💻. Код нужно, хотя бы раз запускать🚀, а ИИшки пока так не умеют, да и вряд ли скоро научатся😐.

Кроме того, у языковых моделей отсутствует понимание сути вещей👁, и это не позволяет им заглянуть глубже. Они уже довольно хорошо понимают👍, что они делают, но никак не могут понять, зачем🤔. Соответственно, не могут понять, почему один способ решить задачу лучше другого👎. Отсюда дикие проблемы с оптимизацией, куча багов🐛 и абсолютно кривой геймплей😂.

🪕 – А ПРИ КОММУНИЗМЕ ВСЕ БУДЕТ ЗАЕБИСЬ,
ОН НАСТУПИТ СКОРО, НАДО ТОЛЬКО ПОДОЖДАТЬ
🤡 – Заходят в бар Python, Java и C# разработчики, а бармен им говорит: "А меня нейросетью не заменить"
И засмеялся так неприятно

НАВИГАЦИЯ

📜 Оглавление по статьям
Сохраняйте в закладки🌟, по мере выхода постов в канале она будет обновляться🔄.

💵 Поддержка и цены
Подушню про код в лс целый час (за деньги)😎. Ну и задонатить, если просто нравится канальчик🥰.

📱 Лайфкодинг и игры на твиче
Minecraft, Mindustry, и вообще всякое🎮. Ну и программирование, разумеется, куда ж без него👨‍💻.

📱 Дискордик
Помурчать😻 и обсудить программирование💬, предложить идеи для игр✍️ (как сделать👨‍💻, так и поиграть🕹).

📱 Склад го(в/д)ноты (git)
Посмотреть проекты там можно👁, поставить звездочки👍.

🌎 Наш Minecraft-сервер
Тут я, BO3bMAK и еще много друзей❤️. Присоединяйся расслабиться после кодинга👾!

🗿 Гайд по реакциям
Чтобы быстрее влиться в атмосферу канала, локальные шутки выкупать🎸.

SOLIDное программирование #3

А мы продолжаем разбирать принципы проектирования. В прошлый раз выяснили, что открыть, а что закрыть, а теперь будем решать, как правильно подставлять (крысить).

Оглавление:
S – Single Responsibility
O – Open-Closed
L – Liskov Substitution📍
I – Interface Segregation
D – Dependency Inversion
(Bonus) DRY – Don`t repeat yourself

📯L – Liskov Substitution

Пропустим матан от Лисков👩‍🔬, давая определение от любимца публики Боба Мартина😎:

– функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом🤷‍♀️.

Ну, вроде, базированная база, но давайте разберем подробнее✍️.

📯Почему это важно?

Все очень просто. Вот, к примеру, есть у нас класс Enemy😈 с методами ближней⚔️ и дальней🔫 атаки. И, прописывая партизана-снайпера🔭, мы поленились и кинули ему в метод ближнего боя NotImplementedException – один хрен, он за три километра стихарился🥷, и его никто никогда не найдет🔍. Вот тут-то и вылезает г-жа Лисков, и толстенный том вышмата приземляется нам на затылок🔨. Потому что как бы далеко в лесу снайпер ни сидел, все равно какая-нибудь собака подойдет и его за жопу схватит😈. А потом и нас схватит. А все потому что сказано было:

В любое место, куда впихуется базовый класс, должен впихиваться и наследник. Без любых условий🙅‍♂️.

И ладно бы Exception, его мы на Unit-тестах отловим🕸 или, хотя бы, QA нам по роже надает👊. Хуже, когда объект, вроде бы, работает, но возвращает null или другую опасную белиберду✨. Потому что эти гады🐍 могут притвориться нормальными, а потом выскочить в самом неожиданном месте, а концов уже не найти👻.

📯Звоночки со дна (колодца)

И в заключение вот несколько подсказок, которые помогут распознать в себе нехорошего человека🤬:

1. Возникает необходимость (или просто интуиция подсказывает) некоторые места использования базового класса завернуть в try-catch.

Не надо🙅‍♂️. Лучше подумай, в чем причина. Потому что все места, которые следует обезопасить🛡 ты никогда не найдешь🔍.

2. if (Obj is Subclass)

Это просто пиздец😁. Переделывай все. Скорее всего, вся архитектура у тебя через жопу🍑. Звони начальнику и выбивай 3-4 недели на рефакторинг📞.

3. Наследник не использует функции базового класса.

В принципе, с этим можно жить👌. До поры до времени🕙. Потому что даже если мы не кидаем Exception или null🎯, отсутствие использования – это часто отсутствие адекватного ответа, потому что класс его просто не знает😐. Это не обязательно приведет к проблемам, но это узкое место, которое может привести к проблемам🚨. Домашнее задание – подумать, почему нельзя наследовать квадрат от прямоугольника (загуглите, если сдаетесь).

🤡 – щас секундочку, щас я позвоню уточню, она че-то не сказала мне, блин...
Подставила меня опять. Блин, не берет еще и...
🍾 – Подставляйте стаканы, у нас тут разливают базу
🪕 – В моем сердце дырка, мне нужна таблетка💊🫦