Barolina · February 6, 2023 12:01 · Feb 6, 2023 · Feb 6, 2023 · Feb 6, 2023 · Feb 6, 2023
diff --git a/SOLID for vue.md b/SOLID for vue.md
@@ -76,12 +76,14 @@ _____
 
 ### 5. D -  Dependency inversion principle
 
-Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций. Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций
+Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций. 
+Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций.
 
-В классическом программирование классы инициируются через new Class()
-Подменить реализацию нижнего уровня не возможно
+В классическом программирование классы инициируются через new Class().
+
+Подменить реализацию нижнего уровня не возможно.
 Как результат уровни зависят друг от друга, логику абстракций сложно удержать в одном месте и не размывать по разным слоям
-Невозможно написать хорошие юнит тесты
+Невозможно написать хорошие юнит тесты.
 
 **Плохой пример** -  прямая   зависсимость 
 
@@ -93,7 +95,9 @@ _____
 ![image](https://user-images.githubusercontent.com/5443003/216918757-1c4b05c3-8761-4795-b411-d0925cafbc8d.png)
 
 
-Тут видно что все наши зависимости стали инвертируемы. То есть теперь не верхние модули зависят от нижних, а нижние от верхних. На этом рисунки у каждого компонента есть свой собственный интерфейс, и этот компонент знает о нижнем классе, только то что может знать интерфейс. При этом модуль нижнего уровня не может общаться с модулем верхнего уровня напрямую, только через его интерфейс.
+Тут видно что все наши зависимости стали инвертируемы. 
+
+То есть теперь не верхние модули зависят от нижних, а нижние от верхних. На этом рисунки у каждого компонента есть свой собственный интерфейс, и этот компонент знает о нижнем классе, только то что может знать интерфейс. При этом модуль нижнего уровня не может общаться с модулем верхнего уровня напрямую, только через его интерфейс.
 
 ```
 class PdfFormatter
@@ -113,12 +117,14 @@ class Printer
 **Особенности принципа**
 
 изменения реализации модулей низкого уровня не должны изменить модули высокого уровня (проблема абстракции или отсутствие инверсии)
-Языки программирования предостовляют свои классы высокого уровня такие как String, Date, Time, и т.п. И их использование не создает ни какой проблемы зависимостей. Потому что эти зависимости статичны, в них ничего не меняется.
-В идеале интерфейс должен быть общим и не от кого ни зависить
-Всегда помните, изменяя интерфейс абстракции, меняется реализация нижнего слоя
-Данный принцип позволяет создать слоистость приложения
-Более высокие модули реализуют бизнес модель приложения.
-Низкие модули реализуют конкретные действия (запросы в БД, сложные вычисления и т.д.) Их удобно переиспользовать в других программах в виде библиотек и общих модулей.
+
+- Языки программирования предостовляют свои классы высокого уровня такие как String, Date, Time, и т.п. И их использование не создает ни какой проблемы зависимостей. Потому что эти зависимости статичны, в них ничего не меняется.
+
+- В идеале интерфейс должен быть общим и не от кого ни зависить.
+- Всегда помните, изменяя интерфейс абстракции, меняется реализация нижнего слоя.
+- Данный принцип позволяет создать слоистость приложения.
+- Более высокие модули реализуют бизнес модель приложения.
+- Низкие модули реализуют конкретные действия (запросы в БД, сложные вычисления и т.д.) Их удобно переиспользовать в других программах в виде библиотек и общих модулей.
 
 
 **Суть принципа**

diff --git a/SOLID for vue.md b/SOLID for vue.md
@@ -8,7 +8,7 @@
 
 ___ 
 
-### 1.  S 
+### 1.  S - Single responsibility principle
 
  - у компонента  должна  быть только  одна  причина для изменения 
  - соберите водеино, то что меняется  по тем же  причинам  и отделите те вещи, которые меняются по разным  причинам.
@@ -26,7 +26,7 @@ ___
 
  ____ 
 
- ### 2. O  
+ ### 2. O  - Open-close principle
 
 - Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.
 
@@ -50,7 +50,7 @@ switch (name) {
 
 ____
 
-### 3. L 
+### 3. L - Liskov substitution principle
 
 Данный принцип касается наследование классов. Точнее он описывает то, как надо правильно создавать наследование.
 
@@ -60,7 +60,7 @@ ____
 
 ____
 
-### 4. I 
+### 4. I - Interface segregation principle
 
 **Кратко** - универсальность  не  всегда  хороша 
 
@@ -74,7 +74,7 @@ ____
 
 _____
 
-### 5. D 
+### 5. D -  Dependency inversion principle
 
 Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций. Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций
 

diff --git a/SOLID for vue.md b/SOLID for vue.md
@@ -1,36 +1,39 @@
-Все принципы  дядюшки  Боба: 
+### Все принципы  дядюшки  Боба: 
 
 - Single responsibility principle
 - Open-close principle
 - Liskov substitution principle
 - Interface segregation principle
 - Dependency inversion principle
 
+___ 
 
-1.  S 
+### 1.  S 
 
  - у компонента  должна  быть только  одна  причина для изменения 
  - соберите водеино, то что меняется  по тем же  причинам  и отделите те вещи, которые меняются по разным  причинам.
 
- Когда  нужен: 
+**Когда  нужен:** 
 
  - Нужно сделать код гибким и легко изменяемым.
  - Сложно заранее определить вектор изменений.
  - Разделение функционала — долгая и сложная операция, нежели его объединение, поэтому отдавайте предпочтение декомпозиции. То есть старайтесь сразу создать архитектуру из небольших, независимых друг от друга сущностей.
 
- Когда нет 
+ **Когда нет** 
 
  - Заранее известно о неизменяемости кода в конкретном месте
  - Решение сильно усложняет разработку и поддержку кода. Всегда нужно сохранять баланс между количеством классов и их необходимостью.
 
- 2. O  
+ ____ 
 
- - Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.
+ ### 2. O  
+
+- Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.
 
 - То есть класс должен быть создан таким образом, что бы поведение класса можно было бы дополнить в любой момент. По мере изменения требований мы должны иметь возможность дополнить класс новым функционалом.
 - При добавление нового функционала нельзя вносить изменения в исходный код такого класса. То есть весь новый код не должен затрагивать старый.
 
-Сигнал,  когда   нарушается  данный принцип  
+**Сигнал,  когда   нарушается  данный принцип**  
 
 ```
 switch (name) {
@@ -41,30 +44,37 @@ switch (name) {
 }
 ```
 
-Суть принципа
+**Суть принципа**
+
 Изменения в программе должны происходить при написание нового кода, а не модификации старого.
 
-- L 
+____
+
+### 3. L 
 
 Данный принцип касается наследование классов. Точнее он описывает то, как надо правильно создавать наследование.
 
-Цель принципа
+**Цель принципа**
+
 Помогает сделать правильное наследование классов.
 
+____
 
-- I 
+### 4. I 
 
-Кратко - универсальность  не  всегда  хороша 
+**Кратко** - универсальность  не  всегда  хороша 
 
- Клиенты не должны попадать в зависимость от методов, которыми они не пользуются
+Клиенты не должны попадать в зависимость от методов, которыми они не пользуются
 
- Цель принципа:
+**Цель принципа:**
 
 - Принцип борется с толстыми интерфейсами (то есть интерфейсами на все случаи жизни)
 - По сути это принцип персональной отвественности, но для интерфейсов (то есть каждый интерфейс должен делать одну свою задачу)
 - Интерфейс должен быть абстрактным (иметь универсальное имя и никому не принадлежать)
 
-- D 
+_____
+
+### 5. D 
 
 Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций. Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций
 
@@ -73,12 +83,12 @@ switch (name) {
 Как результат уровни зависят друг от друга, логику абстракций сложно удержать в одном месте и не размывать по разным слоям
 Невозможно написать хорошие юнит тесты
 
-Плохой пример -  прямая   зависсимость 
+**Плохой пример** -  прямая   зависсимость 
 
 ![image](https://user-images.githubusercontent.com/5443003/216918676-2bf7482c-266a-4a21-b498-906ffa5a0535.png)
 
 
-Хороший пример 
+**Хороший пример** 
 
 ![image](https://user-images.githubusercontent.com/5443003/216918757-1c4b05c3-8761-4795-b411-d0925cafbc8d.png)
 
@@ -100,7 +110,8 @@ class Printer
   function print(PdfFormatter formatter)
  ```
 
- Особенности принципа
+**Особенности принципа**
+
 изменения реализации модулей низкого уровня не должны изменить модули высокого уровня (проблема абстракции или отсутствие инверсии)
 Языки программирования предостовляют свои классы высокого уровня такие как String, Date, Time, и т.п. И их использование не создает ни какой проблемы зависимостей. Потому что эти зависимости статичны, в них ничего не меняется.
 В идеале интерфейс должен быть общим и не от кого ни зависить
@@ -110,7 +121,8 @@ class Printer
 Низкие модули реализуют конкретные действия (запросы в БД, сложные вычисления и т.д.) Их удобно переиспользовать в других программах в виде библиотек и общих модулей.
 
 
- Суть принципа
+**Суть принципа**
+
 Зависимости должны строиться относительно абстракций, а не деталей.
 
 

diff --git a/SOLID for vue.md b/SOLID for vue.md
@@ -0,0 +1,117 @@
+Все принципы  дядюшки  Боба: 
+
+- Single responsibility principle
+- Open-close principle
+- Liskov substitution principle
+- Interface segregation principle
+- Dependency inversion principle
+
+
+1.  S 
+
+ - у компонента  должна  быть только  одна  причина для изменения 
+ - соберите водеино, то что меняется  по тем же  причинам  и отделите те вещи, которые меняются по разным  причинам.
+
+ Когда  нужен: 
+
+ - Нужно сделать код гибким и легко изменяемым.
+ - Сложно заранее определить вектор изменений.
+ - Разделение функционала — долгая и сложная операция, нежели его объединение, поэтому отдавайте предпочтение декомпозиции. То есть старайтесь сразу создать архитектуру из небольших, независимых друг от друга сущностей.
+
+ Когда нет 
+
+ - Заранее известно о неизменяемости кода в конкретном месте
+ - Решение сильно усложняет разработку и поддержку кода. Всегда нужно сохранять баланс между количеством классов и их необходимостью.
+
+ 2. O  
+
+ - Программные объекты (классы, модули, функции и т.п.) должны быть открыты для расширения, но в то же время закрыты для модификации.
+
+- То есть класс должен быть создан таким образом, что бы поведение класса можно было бы дополнить в любой момент. По мере изменения требований мы должны иметь возможность дополнить класс новым функционалом.
+- При добавление нового функционала нельзя вносить изменения в исходный код такого класса. То есть весь новый код не должен затрагивать старый.
+
+Сигнал,  когда   нарушается  данный принцип  
+
+```
+switch (name) {
+  case 'Shape':
+    return new Shape()
+  case 'Rectangle':
+    return new Rectangle()
+}
+```
+
+Суть принципа
+Изменения в программе должны происходить при написание нового кода, а не модификации старого.
+
+- L 
+
+Данный принцип касается наследование классов. Точнее он описывает то, как надо правильно создавать наследование.
+
+Цель принципа
+Помогает сделать правильное наследование классов.
+
+
+- I 
+
+Кратко - универсальность  не  всегда  хороша 
+
+ Клиенты не должны попадать в зависимость от методов, которыми они не пользуются
+
+ Цель принципа:
+
+- Принцип борется с толстыми интерфейсами (то есть интерфейсами на все случаи жизни)
+- По сути это принцип персональной отвественности, но для интерфейсов (то есть каждый интерфейс должен делать одну свою задачу)
+- Интерфейс должен быть абстрактным (иметь универсальное имя и никому не принадлежать)
+
+- D 
+
+Модули высокого уровня не должны зависеть от модулей низкого уровня. Оба типа модулей обязаны зависеть от абстракций. Абстракции не должны зависеть от подробностей. Подробностям следует зависеть от абстракций
+
+В классическом программирование классы инициируются через new Class()
+Подменить реализацию нижнего уровня не возможно
+Как результат уровни зависят друг от друга, логику абстракций сложно удержать в одном месте и не размывать по разным слоям
+Невозможно написать хорошие юнит тесты
+
+Плохой пример -  прямая   зависсимость 
+
+![image](https://user-images.githubusercontent.com/5443003/216918676-2bf7482c-266a-4a21-b498-906ffa5a0535.png)
+
+
+Хороший пример 
+
+![image](https://user-images.githubusercontent.com/5443003/216918757-1c4b05c3-8761-4795-b411-d0925cafbc8d.png)
+
+
+Тут видно что все наши зависимости стали инвертируемы. То есть теперь не верхние модули зависят от нижних, а нижние от верхних. На этом рисунки у каждого компонента есть свой собственный интерфейс, и этот компонент знает о нижнем классе, только то что может знать интерфейс. При этом модуль нижнего уровня не может общаться с модулем верхнего уровня напрямую, только через его интерфейс.
+
+```
+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, и т.п. И их использование не создает ни какой проблемы зависимостей. Потому что эти зависимости статичны, в них ничего не меняется.
+В идеале интерфейс должен быть общим и не от кого ни зависить
+Всегда помните, изменяя интерфейс абстракции, меняется реализация нижнего слоя
+Данный принцип позволяет создать слоистость приложения
+Более высокие модули реализуют бизнес модель приложения.
+Низкие модули реализуют конкретные действия (запросы в БД, сложные вычисления и т.д.) Их удобно переиспользовать в других программах в виде библиотек и общих модулей.
+
+
+ Суть принципа
+Зависимости должны строиться относительно абстракций, а не деталей.
+
+
+