Что такое SOLID?

А, SOLID, говоришь? Ну это, блядь, классика жанра, как водка под селёдку. Сидят себе пять принципов, такие важные, а без них код превращается в такое месиво, что хоть святых выноси. Ёпта, сейчас разжую, как есть.

Ну смотри, первый принцип — S (Single Responsibility). Это типа «одна задача — один чувак». Представь, у тебя есть класс Order, который и данные хранит, и проверяет их, и в базу пихает. Это же пиздец, манда с ушами получается! Он везде суёт свой нос. Я обычно так не делаю — разбиваю на три отдельных увальня: сам Order (просто данные, как мешок картошки), OrderValidator (этот только орёт, если что не так) и OrderRepository (молча тащит этот мешок в базу). Каждый знает своё место, и волнение ебать — когда надо поменять логику сохранения, ты не трогаешь валидацию. Удобно, бля.

Дальше O (Open/Closed). Суть в том, что твой код должен быть как хороший диван: на него можно новых подушек накинуть (расширить), но сам диван перешивать не надо (закрыт для модификации). Раньше, бывало, пишешь метод CalculateDiscount(User user), а внутри куча if: если юзер обычный — скидка 5%, если премиум — 10%. Потом приходит новый тип «супер-пупер», и ты лезешь в этот метод, дописываешь ещё один if. Это пиздопроебибна история, потому что с каждым разом метод становится страшнее. Я делаю иначе: создаю интерфейс IDiscountStrategy и кучу классов: RegularDiscount, PremiumDiscount. Когда появляется новый тип, я просто создаю новый класс SuperPuperDiscount и подсовываю его в общую систему. Старый код даже не чихнул. Красота!

L (Liskov Substitution) — это, блядь, про то, что дети должны родителей не позорить. Если у тебя есть класс Rectangle (прямоугольник) с методами SetWidth и SetHeight, и ты от него наследуешь Square (квадрат), то жди беды. Потому что у квадрата ширина и высота всегда равны, а значит, меняя ширину через SetWidth, ты неявно меняешь и высоту. Получается, подсунув Square туда, где ожидается Rectangle, ты всё ломаешь. Сам от себя охуеешь, когда баги попрут. Поэтому тут надо либо общий интерфейс IShape сделать, либо вообще по-другому архитектуру выстраивать. Наследование — штука опасная, чувак.

I (Interface Segregation) — это когда лучше много мелких и конкретных договоров, чем один толстый, на который всем похуй. Был у меня в проекте интерфейс IMonsterPrinter: он умел Print, Scan, Fax, MakeCoffee и, кажется, WorldPeace. Проблема в том, что простой принтер SimplePrinter был вынужден реализовывать все эти методы, даже Scan и Fax, для которых у него просто физически ничего нет! Он возвращал throw new NotImplementedException(), что есть чистой воды распиздяйство. Я разделил этого монстра на IPrinter, IScanner, IFax. Теперь SimplePrinter реализует только IPrinter, и ему не стыдно. А сложное устройство может реализовать хоть все три. Каждый доволен.

И наконец, D (Dependency Inversion). Это принцип, который говорит: «Не завись от конкретики, завись от абстракции». Раньше класс ReportService мог внутри себя тупо делать var repo = new MySqlRepository();. И всё, приехали. Хочешь протестировать? Хуй с горы — он привязан к реальной базе. Захотел перейти на PostgreSQL? Придётся лезть в кишки ReportService и менять. Это же ёперный театр! Теперь я делаю так: ReportService в конструкторе принимает не конкретную реализацию, а интерфейс IRepository. И тогда я могу дать ему в тестах FakeRepository (заглушку), а в продакшене — MySqlRepository или любую другую. Модули верхнего уровня (ReportService) и нижнего (MySqlRepository) теперь зависят не друг от друга, а от общей абстракции IRepository. Гибкость — овердохуища!

Если коротко, то соблюдение этих принципов — это как не жрать на ночь тяжёлого: снижает coupling (связность, когда всё держится на соплях) и повышает cohesion (сцепление, когда код внутри одного модуля делает одно дело). В итоге система не разваливается от одного чиха, и жить становится проще. Ну, как думаешь, э бошка?