Barolina/SOLID for vue.md

## SOLID for vue.md

      
    Raw
  

              SOLID  for vue.md
            
          
    Все принципы  дядюшки  Боба:


Single responsibility principle
Open-close principle
Liskov substitution principle
Interface segregation principle
Dependency inversion principle


1.  S - Single responsibility principle


у компонента  должна  быть только  одна  причина для изменения
соберите водеино, то что меняется  по тем же  причинам  и отделите те вещи, которые меняются по разным  причинам.

Когда  нужен:

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

Когда нет

Заранее известно о неизменяемости кода в конкретном месте
Решение сильно усложняет разработку и поддержку кода. Всегда нужно сохранять баланс между количеством классов и их необходимостью.


2. O  - Open-close principle


Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.


То есть класс должен быть создан таким образом, что бы поведение класса можно было бы дополнить в любой момент. По мере изменения требований мы должны иметь возможность дополнить класс новым функционалом.


При добавление нового функционала нельзя вносить изменения в исходный код такого класса. То есть весь новый код не должен затрагивать старый.


Сигнал,  когда   нарушается  данный принцип
switch (name) {
  case 'Shape':
    return new Shape()
  case 'Rectangle':
    return new Rectangle()
}

Суть принципа
Изменения в программе должны происходить при написание нового кода, а не модификации старого.

3. L - Liskov substitution principle

Данный принцип касается наследование классов. Точнее он описывает то, как надо правильно создавать наследование.
Цель принципа
Помогает сделать правильное наследование классов.

4. I - Interface segregation principle

Кратко - универсальность  не  всегда  хороша
Клиенты не должны попадать в зависимость от методов, которыми они не пользуются
Цель принципа:

Принцип борется с толстыми интерфейсами (то есть интерфейсами на все случаи жизни)
По сути это принцип персональной отвественности, но для интерфейсов (то есть каждый интерфейс должен делать одну свою задачу)
Интерфейс должен быть абстрактным (иметь универсальное имя и никому не принадлежать)


5. D -  Dependency inversion principle

Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций.
Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций.
В классическом программирование классы инициируются через new Class().
Подменить реализацию нижнего уровня не возможно.
Как результат уровни зависят друг от друга, логику абстракций сложно удержать в одном месте и не размывать по разным слоям
Невозможно написать хорошие юнит тесты.
Плохой пример -  прямая   зависсимость

Хороший пример

Тут видно что все наши зависимости стали инвертируемы.
То есть теперь не верхние модули зависят от нижних, а нижние от верхних. На этом рисунки у каждого компонента есть свой собственный интерфейс, и этот компонент знает о нижнем классе, только то что может знать интерфейс. При этом модуль нижнего уровня не может общаться с модулем верхнего уровня напрямую, только через его интерфейс.
class PdfFormatter
  function format(data)
    # format data to Pdf logic
  
class HtmlFormatter
  function format(data)
    # format data to Html logic
  
class Printer
  function Printer(data) 
    this.data = data
  function print(PdfFormatter formatter)

Особенности принципа
изменения реализации модулей низкого уровня не должны изменить модули высокого уровня (проблема абстракции или отсутствие инверсии)


Языки программирования предостовляют свои классы высокого уровня такие как String, Date, Time, и т.п. И их использование не создает ни какой проблемы зависимостей. Потому что эти зависимости статичны, в них ничего не меняется.


В идеале интерфейс должен быть общим и не от кого ни зависить.


Всегда помните, изменяя интерфейс абстракции, меняется реализация нижнего слоя.


Данный принцип позволяет создать слоистость приложения.


Более высокие модули реализуют бизнес модель приложения.


Низкие модули реализуют конкретные действия (запросы в БД, сложные вычисления и т.д.) Их удобно переиспользовать в других программах в виде библиотек и общих модулей.


Суть принципа
Зависимости должны строиться относительно абстракций, а не деталей.