Русский
Русский
English
Статистика
Реклама

Справочная разбираемся с принципами SOLID

Расскажем, кто их придумал и в чем они заключаются. Также поговорим о критике этого подхода о том, почему некоторые разработчики отказываются следовать 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


Источник: habr.com
К списку статей
Опубликовано: 06.10.2020 22:07:22
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании 1cloud.ru

Программирование

1cloud

Solid

Ооп

Справочная

Основы разработки

Методологии разработки

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru