Привет, дорогой друг!
Сегодня я тебе объясню принципы SOLID максимально понятным способом.
Для того чтобы совсем упростить задачу, в этом тексте не будет ни единой строчки кода.
Представь себе, что ты решил заняться бизнесом.
Первым делом ты организуешь небольшую торговую компанию. Ты только начинаешь свой путь в бизнесе, и поэтому всё делаешь сам. И закупаешь товар, и развозишь его по точкам, и ведёшь учёт, и ремонтируешь грузовую газель.
С момента написания предыдущей статьи я находился под пристальным вниманием. Попытка опубликовать материалы на англоязычных платформах обернулась фиаско — в первые же минуты легионы последователей тайного братства обрушились с критикой:
— Нет никакой организации! — вопили они.
Подозреваю, что слежка велась через мой телеграм-канал.
В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.
Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.
Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).
Зачастую, когда речь заходит про принцип инверсии зависимостей, можно услышать, что инверсия зависимостей (далее DIP) — это что-то там про зависимость от абстракций, и приводятся примеры, где в качестве «плохого» случая, используются конкретные классы, а в исправленном случае, используются абстрактные классы или интерфейсы. Но такая трактовка принципа в корне неверна.
Почему такая трактовка неверна и в чем же суть принципа — об этом и пойдет речь далее.
С переводом терминов Low Coupling и High Cohession есть путаница. Чтобы её избежать - я буду применять эти термины без перевода.
SOLID улучшает coupling, но ухудшает читабельность
Для большинства проектов читабельность важнее связности
В начале разработки проекта делайте упор на читабельность и ясность
В свое время FastAPI прогремел как гром среди ясного неба - тут тебе и минималистичный API аля-Flask (все устали от Django, диктующего свои правила), и OpenAPI документация из коробки, и удобное тестирование, и хайповая асинхронность. Буквально все, что нужно для свободы творчества, и никаких ограничений! Да еще и Depends завезли! В тот момент это был культурный шок - Dependency Injection в Python? Разве это не что-то из Java?
FastAPI показал, что DI - это паттерн, упрощающий разработку вне зависимости от языка программирования. Теперь DIЧитать полностью »
Здравствуйте, друзья! Меня зовут Константин, я python backend developer из компании «Окенит». Сегодня я хочу рассказать свое видение проблемы новичка при ознакомлении с принципами SOLID, описанными в книге «Стерильная Архитектура» Робина Мартерта.
Каждый программист хоть раз слышал о принципах SOLID. На собеседованиях и экзаменах в вузах многие из нас пытались вспомнить, о чем же был тот самый принцип Лисков. Однако вряд ли цель преподавателей и интервьюеров — заставить нас заучивать строчки из учебников. SOLID действительно помогает писать качественный код, когда во всем разберешься! Если вы этого еще не сделали, добро пожаловать под кат. Еще раз взглянем на то, как устроены всем известные принципы. Обещаю — без духоты, все рассмотрим на примерах с котиками.Читать полностью »
В этой статье я расскажу о двухлетнем эксперименте, проводимом над моим пет-проектом, интерпретатором ЯП HydraScript. Почему к разработке из области системного программирования были применены промышленные практики, и зачем конструированию компиляторов нужен Domain Driver Design с чистой архитектурой?
