Design Patterns

Author: pvaviloff

architecture/design-patterns.md

@@ -1 +1,63 @@
-## Паттерны проектирования (Design Patterns)
+## Паттерны проектирования (Design Patterns)
+
+Паттерны нужны только там, где они уместны. У каждого паттерна есть собственная цель и область применения. 
+Если нет точной уверенности что использование паттерна решит проблему масштабирования приложения, то и использование его не рекомендуется. 
+
+Так же есть один из самых распространенных паттернов так же один из самых полезных - это фабричный метод. 
+Его самый важный плюс в том, что его цель отделить конкретику от общего процесса. При этом достигается инкапсуляция. 
+Так же соблюдается инверсия зависимостей. И реализация не уходит в излишнюю абстракцию, что сохраняет читабельность, и не делает из кода лазанью. 
+
+Типовая задача звучит примерно всегда одинаково: У нас есть разные сущности, которые должны иметь одинаковое поведение. 
+
+Возьмем к примеру склад на который товар может прийти различными способами и будет различие в оприходовании, но выгружен на одном и том же складе. 
+Допустим нам его может привезти грузовик, или он может прийти к нам пароходом. 
+```php
+interface IArrival 
+{
+    public function getProducts(): array;
+}
+
+class TruckArrival implements IArrival
+{
+    public function getProducts(): array
+    {
+    ...
+    }
+}
+
+class ShipArrival implements IArrival
+{
+    public function getProducts(): array
+    {
+    ...
+    }
+}
+
+class StockControl
+{
+    const TRUCK_ARRIVAL = 1;
+    const SHIP_ARRIVAL = 2;
+
+    private function getArrival(int $arrivalType): IArrival
+    {
+        if ($arrivalType === self::TRUCK_ARRIVAL) {
+            return new TruckArrival();
+        }
+        if ($arrivalType === self::SHIP_ARRIVAL) {
+            return new ShipArrival();
+        }
+    }
+    
+    public function control()
+    {
+        ...
+        $arrival = $this->getArrival($arrivalType);
+        $products = $arrival->getProducts();
+        ...
+    }
+}
+```
+
+Таким образом происходит деление задачи на две подзадачи. Первое определить сам товар и оприходовать его. Вторая разместить на складе.
+
+Так же есть разные вариации, трактования и подтипы паттернов, что привело к нарушению принципа не плодить сущности сверх необходимого.

architecture/grasp.md

@@ -89,7 +89,6 @@ class Bill {
         ...
     }
 }
-
 ```
 
 Из примера видно, что у продукта из счёта есть свойства, которые позволяют рассчитать стоимость одной позиции. Значит она и должна быть рассчитана в `BillProduct`.

architecture/oop.md

@@ -7,25 +7,29 @@
 
 В пример можно привести формирование одного счета в кафе, где за бар и еду платим отдельно из-за разного формирования цены.
 ```php 
-interface IBill {
+interface IBill 
+{
     public function getSum(): float;
 }
 
-class FoodBill implements IBill {
+class FoodBill implements IBill 
+{
     public function getSum(): float
     {
         ...
     }
 }
 
-class DrinkBill implements IBill {
+class DrinkBill implements IBill 
+{
     public function getSum(): float
     {
         ...
     }
 }
 
-class FullBill {
+class FullBill 
+{
     private array $bills = [];
 
     public function addBill(IBill $bill): void
@@ -43,8 +47,8 @@ class FullBill {
     }
 }
 ```
-При данной реализации добавить отдельный расчет за табачные изделия не составит труда. Но тут так же играет роль сам бизнес процесс, который и диктует требования к реализации.
-Всегда из поставленной задачи необходимо попытаться предположить как может измениться процесс. Так как можно усложнить приложение там, где никогда процесс работы приложения не поменяется.
+При данной реализации добавить отдельный расчет, реализующий другую логику формирования суммы, не составит труда. Но тут так же играет роль сам бизнес процесс, который и диктует требования к реализации.
+Всегда из поставленной задачи необходимо попытаться предположить как может измениться процесс. Так как можно усложнить приложение там, где никогда процесс работы не поменяется.
 
 Наследование является достаточно спорным решением для достижения полиморфизма из-за рисков создания God object и/или уход в излишнюю абстракцию, которая приведет к сильной зависимости(связанности) классов между собой вдобавок усложнив читабельность кода.
 По возможности не используйте абстрактные классы, если не достигается полиморфизм.

architecture/solid.md

@@ -5,34 +5,39 @@
 Dependency Inversion (Принцип инверсии зависимостей) главная цель данного принципа уменьшить зацепление классов между собой.
 
 ```php
-interface FileContract {
+interface FileContract 
+{
     public function getDocumentBody(): string;
 }
 
-class Bill implements FileContract {
+class Bill implements FileContract 
+{
     public function getDocumentBody(): string
     {
         ...
         return "Bill sum";
     }
 }
 
-class Report implements FileContract {
+class Report implements FileContract 
+{
     public function getDocumentBody(): string
     {
         ...
         return "Report data";
     }
 }
 
-class Printer {
+class Printer 
+{
     public function execute(FileContract $file) 
     {
         // логика печати
     }
 }
 
-class PrintBill {
+class PrintBill 
+{
     public function execute() 
     {
         $printer = new Printer();
@@ -42,7 +47,8 @@ class PrintBill {
     }
 }
 
-class PrintReport {
+class PrintReport 
+{
     public function execute() 
     {
         $printer = new Printer();
@@ -62,7 +68,8 @@ Dependency injection при помощи абстракции один раз н
 Примеры реализации есть в вендорном пакете [php di](https://github.com/PHP-DI/PHP-DI), [symfony](https://symfony.com/doc/current/components/dependency_injection.html) и [laravel](https://laravel.com/docs/8.x/providers) 
 
 ```php
-class PrintReport {
+class PrintReport 
+{
     private Printer $printer;
 
     public function __construct(Printer $printer)