Расскажем, кто их придумал и в чем они заключаются. Также поговорим о критике этого подхода — о том, почему некоторые разработчики отказываются следовать SOLID-методологиям.


Фото — nesa — Unsplash

Акроним


SOLID — обозначает пять первых принципов объектно-ориентированного программирования:

  • Единственной ответственности (SRP). Один модуль/класс — одна задача. Кажется, что-то такое мы уже обсуждали, когда разбирали «философию Unix» вместе с принципами KISS.
  • Открытости/закрытости (OCP). Компоненты — расширяемые и немодифицируемые. Его основоположником считают Бертрана Мейера (Bertrand Meyer) — автора Eiffel.
  • Подстановки (LSP). Разработчик должен иметь возможность заменить тип на подтип, не сломав систему. Иерархию типов нужно тщательно моделировать, чтобы избежать путаницы. Принцип предложила Барбара Лисков (Barbara Liskov) — один из авторов Clu.
  • Разделения интерфейса (ISP). Роберт Мартин (Robert Martin), международно признанный эксперт в области разработки ПО, определил этот принцип следующим образом: «программные сущности не должны зависеть от методов, которые они не используют». Так можно упростить рефакторинг в случае внесения изменений в логику работы ПО.
  • Инверсии зависимостей (DIP). Управляющие компоненты должны быть абстрагированы от модулей нижних уровней, а детали — не зависеть от абстракций и модулей верхних уровней. Роберт Мартин предложил и этот пункт (вот текст его оригинальной публикации).

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

Кто вывел SOLID


Как вы уже успели догадаться, за основную часть принципов отвечал именно Дядя Боб. Комплексно он описал их в работе «Design Principles and Design Patterns» 2000 года, а сам акроним SOLID уже позже предложил инженер Майкл Фэзерс (Michael Feathers). Если интересно, у Майкла есть книга, где он дает рекомендации о том, как «оживить» legacy-систему и не сойти с ума по ходу дела.


Фото — Oskar Yildiz — Unsplash

Задача SOLID — способствовать разработке приложений, которые легко поддерживать и расширять в течение долгого времени. Но этот свод рекомендаций часто подвергают критике.

За что критикуют


Иногда эти принципы называют «слишком расплывчатыми», что усложняет их практическое использование. Программист и писатель Джоэл Спольски (Joel Spolsky) в одном из выпусков The StackOverflow Podcast также отметил, что SOLID-методология слишком утопична и вынуждает разработчиков тратить время на избыточный код фактически «ради галочки».

Он считает, что не нужно заранее пытаться учесть все возможные варианты развития событий и просто программировать, постепенно исправляя недочеты, а не опираться на мнимую «систему безопасности». Спольски не отменяет значимости принципов, но называет их чрезмерными.

Есть мнение, что SOLID-код имеет слабую связность и его легко тестировать, но очень сложно понимать (в критике используется слово «unintelligible»). Программисту приходится писать множество детализированных интерфейсов и небольших классов, которые больше отвлекают и путают, чем помогают наладить какую-то систему. С этим утверждением соглашаются многие, кто считает, что достаточно фокусироваться на простоте кода, чтобы его могли поддерживать другие разработчики.


Фото — Kevin Canlas — Unsplash

В тематическом треде на Hacker News говорят и о том, что гораздо большее значение имеет выбор архитектуры, технологического стека и управление зависимостями проекта, а не основополагающие принципы, по которым строится его написание. Здесь вновь указывают на излишнюю сложность старта с комплексного проектирования системы, указывая уже на принцип YAGNI или «You aren't gonna need it». В какой-то степени это — очередной ремикс классического KISS-подхода.

Стоит признать, что есть и множество высказываний в защиту SOLID. Так, один из резидентов HN говорит, что следование эти принципам поможет быстро заменить условную библиотеку, если на уровне абстракции что-то пойдет не совсем так. Достаточно будет удостовериться в выполнении тестов для новой реализации и на этом все, максимум — дополнительно проверить зависимости для старой версии класса и по мере необходимости использовать доработанный, чтобы тесты прошли успешно. Тогда в коде не будет и «излишней сложности», а тем, кто будет заниматься им впоследствии, не будет грозить так называемый синдром неприятия чужой разработки.

Важно помнить, что принципы SOLID являются лишь рекомендациями, а не строгими правилами. И всегда будут кейсы, когда их лучше придерживаться, а когда — отступить.


О чем мы пишем в корпоративном блоге 1cloud.ru:

Необычные приглашения на собеседование — от HTTP-заголовка до сообщения в поисковике
Почему разработчики дороже денег, как их сохранить и приумножить
Группа разработчиков предлагает перейти на UTF-8


Новые публикации у нас на Хабре: