-
SOLID
- (S) Single-responsibility principle (Принцип единственной ответственности)
- (O) Open–closed principle (Принцип открытости-закрытости)
- (L) Liskov substitution principle (Принцип подстановки Лисков)
- (I) Interface segregation principle (Принцип разделения интерфейсов)
- (D) Dependency inversion principle (Принцип инверсии зависимостей)
- Заключение
В этом тексте приводится набор принципов, которые должен знать любой разработчик, и которые следует периодически освежать в памяти. Считайте их своим секретным оружием при программировании. Последовательное применение этих принципов упростит ваш переход от миддла к сеньору. Вы можете обнаружить, что некоторые (вероятно) вы применяете интуитивно. Принципов много. Мы остановимся на семи самых важных. Их использование поможет вам в развитии и позволит стать лучшим программистом. (1)
SOLID
Это наиболее известный принцип разработки ПО.
Solid — это аббревиатура от: (2)
-
Single responsibility,
-
Open-closed,
-
Liskov substitution,
-
Interface segregation
-
Dependency inversion
Подробнее:
(S) Single-responsibility principle (Принцип единственной ответственности)
Его важность невозможно переоценить. Каждый объект, класс и метод должны отвечать только за что-то одно. Если ваш объект/класс/метод делает слишком много, вы получите спагетти-код.
Вот пример:
const saveTodo = async () => { try { response = await saveTodoApi(); showSuccessPop('Success'); window.location.href = '/successPage'; } catch (error) { showErrorPopup(`Error: ${error} `); } }
Этот метод кажется безобидным, но на самом деле он делает слишком много:
-
Сохраняет объект
-
Обрабатывает уведомление в UI
-
Выполняет навигацию
Еще один побочный эффект такого кода – проблемы с тестированием. Запутанный функционал тестировать сложно.
Пример (3): класс, который можно разделить на несколько:
Разделим его на отдельные подклассы:
(O) Open–closed principle (Принцип открытости-закрытости)
Программные объекты должны быть открыты для расширения, но закрыты для модификации. Речь о том, что нельзя переопределять методы или классы, просто добавляя дополнительные функции по мере необходимости.
Хороший способ решения этой проблемы – использование наследования. В JavaScript эта проблема решается с помощью композиции.
Простое правило: если вы изменяете сущность, чтобы сделать ее расширяемой, вы впервые нарушили этот принцип.
Пример (3):
(L) Liskov substitution principle (Принцип подстановки Лисков)
Этот принцип гласит, что объекты старших классов должны быть заменимы объектами подклассов, и приложение при такой замене должно работать так, как ожидается.
(I) Interface segregation principle (Принцип разделения интерфейсов)
Этот принцип был сформулирован Робертом Мартином, когда он консультировал Xerox, и он очевиден.
Объекты не должны зависеть от интерфейсов, которые они не используют
ПО должно разделяться на независимые части. Побочные эффекты необходимо сводить к минимуму, чтобы обеспечивать независимость.
Убедитесь, что вы не заставляете объекты реализовывать методы, которые им никогда не понадобятся.
Вот пример №1:
interface Animal { eat: () => void; walk: () => void; fly: () => void; swim: () => void; }
Не все животные могут fly, walk или swim, поэтому эти методы не должны быть частью интерфейса или должны быть необязательными.
Пример №2: интерфейс, перегруженный методами: (3)
Можно его разбить на несколько независимых:
(D) Dependency inversion principle (Принцип инверсии зависимостей)
Этот принцип невозможно переоценить. Мы должны полагаться на абстракции, а не на конкретные реализации. Компоненты ПО должны иметь низкую связность и высокую согласованность.
Заботиться нужно не о том, как что-то устроено, а о том, как оно работает. Простой пример – использование дат в JavaScript. Вы можете написать для них свой слой абстракции. Тогда если у вас сменится источник получения дат, вам нужно будет внести изменения в одном месте, а не в тысяче.
Иногда добавление этого уровня абстракции требует усилий, но в конечном итоге они окупаются.
В качестве примера взгляните на date-io, в этой библиотеке создан тот уровень абстракции, который позволяет вам использовать её с разными источниками дат.
Пример (3): не рациональный класс — с методом OrderProcessor
Правильно (рефакторинг):
Заключение
Эти принципы не очень сложны. На самом деле, именно простота делает их красивыми. Если вы сбиты с толку, не пытайтесь применять все их сразу. Просто постарайтесь работать осознанно и пробуйте постепенно включать эти принципы в свой рабочий процесс. Использование базовых, но действенных принципов позволит вам стать лучшим программистом и иметь более четкое представление о том, почему вы что-то делаете. Если вы применяете большую часть принципов интуитивно, стоит задумываться и осознавать почему вы делаете что-то определенным образом.
+ см. видео по теме SOLID (3) :
Источники:
(1) https://habr.com/ru/company/itelma/blog/546372/
(2) https://www.youtube.com/watch?v=0qP6Vh8GNM0
(3) Отличное видео по теме с примерами SOLID: https://www.youtube.com/watch?v=47-F0wGz-Vk
Нет Ответов