День 1078.
Избегайте Ненужных Программных Абстракций. Начало
Разработчики ПО любят абстракции. Абстракции — ключ к эффективной разработке. Проблема возникает, когда абстракции вводятся преждевременно, т.е. до того, как они решают реальную нетеоретическую проблему. Добавление абстракций всегда происходит за счёт роста сложности и, если с ними переборщить, начинает замедлять скорость разработки и способность понимать кодовую базу.

Все проблемы в информатике можно решить с помощью ещё одного уровня абстракции… За исключением проблемы слишком большого количества уровней абстракции.
— Батлер Лэмпсон

Мы рассмотрим, как отказ от лишних абстракций может привести к гораздо более чистой кодовой базе со значительно сниженной сложностью, а также повышенной читаемостью и удобством сопровождения. Обсуждаемые вопросы основаны на таких принципах, как «Делай Проще, Тупица» (KISS) и «Вам Этого не Понадобится» (YAGNI), что означает использование абстракции только тогда, когда это даёт значительную и реальную пользу. Давайте рассмотрим некоторые конкретные случаи преждевременных абстракций, которые часто встречаются на практике.

1. Чрезмерная детализация обязанностей
Это может быть абстракция запроса к базе данных в выделенный класс репозитория, абстрагирование HTTP-вызова в сервисный класс или какая-то исключительно внутренняя логика, перемещённая в отдельный компонент.

Обычно это делается для следования принципу единственной ответственности. Если мы выделим каждую крошечную часть логики в отдельный класс, тогда все классы будут иметь сверхчёткие обязанности, и, следовательно, только одну причину для изменения. Проблема в том, что все эти маленькие части, как правило, всё ещё тесно связаны и сильно зависят друг от друга. Если какая-либо коммуникация между частями изменится, часто это будет иметь каскадный эффект, требующий изменений во многих частях. Таким образом, у каждой части может быть только одна причина для изменения, но это бессмысленно, если одно изменение часто требует внесения изменений во многие части.

Кроме того, часто нет реальных практических преимуществ в том, чтобы классы изменялись только по одной причине. На самом деле, внесение изменений в классы, которые выполняют несколько функций, часто предоставляет разработчику гораздо больше контекста, что значительно упрощает понимание изменений и их влияния на окружающий код.

Когда же разделять обязанности? Распространённый случай — когда логику нужно использовать более, чем в одном месте. Если один и тот же HTTP-вызов или запрос к базе требуется в нескольких местах, дублирование логики снижает удобство сопровождения. Тогда будет хорошей идеей перенести код в общий и многократно используемый компонент. Главное не делать этого до того, как это потребуется. Другой допустимый случай — когда логика очень сложна и негативно влияет на читаемость окружающего кода. Если часть логики занимает 300 строк, это как раз тот случай. Но выделение всего нескольких строк в отдельный класс, скорее всего, только ухудшит читаемость и затруднит навигацию по коду. Помните, что разделение обязанностей всегда усложняет структуру кода.

Продолжение следует…

Источник: https://www.daveabrock.com/2021/12/08/do-this-not-that-the-net-6-edition/