|
| 1 | +## GRASP принципы |
| 2 | + |
| 3 | +Принципы GRASP описывают как разделить правильно код на логические части так, чтоб достичь полиморфизма. |
| 4 | + |
| 5 | +Из GRASP понадобится всего один принцип для объединения(Information Expert) и два принципа для разделения логики (Low Coupling и High Cohesion). |
| 6 | + |
| 7 | +Начнем с разделения логики, так как зачастую в проектах без какого-либо этикета написания кода можно встретить или fat model, или fat controller. |
| 8 | +Эти два принципа помогают как в написании нового функционала в новом проекте, так и при рефакторинге старого легаси проекта. |
| 9 | +Руководствуясь логикой, что при создании нового функционала разработчик склонен плодить сущности сверх необходимого, а при доработке наоборот старается не создавать лишних сущностей, необходимо постараться выдерживать баланс. |
| 10 | + |
| 11 | +### Low Coupling |
| 12 | + |
| 13 | +Low Coupling (слабое зацепление) - этот принцип гласит чем меньше `use` в классе тем лучше. |
| 14 | +Самым ярким примером слабого зацепления является антипаттерн God object. |
| 15 | +God object может быть минимально зависим от других объектов при этом содержать в себе реализацию логики не относящуюся к данному объекту, что уменьшает высокую связанность. |
| 16 | + |
| 17 | +### High Cohesion |
| 18 | + |
| 19 | +High Cohesion (высокая связанность) - принцип диктует правило для класса. Класс должен выполнять минимальное количество действий. |
| 20 | +К примеру если класс реализует логику рассылки писем, то этот класс не должен отвечать за формирование содержимого этого письма. |
| 21 | + |
| 22 | +```php |
| 23 | +class Mail { |
| 24 | + protected string $mailTo; |
| 25 | + |
| 26 | + protected string $subject; |
| 27 | + |
| 28 | + protected string $bodyBoilerplate = 'Hi \s'; |
| 29 | + |
| 30 | + public function getMailTo(): string |
| 31 | + { |
| 32 | + return $this->mailTo; |
| 33 | + } |
| 34 | + |
| 35 | + public function getSubject(): string |
| 36 | + { |
| 37 | + return $this->subject; |
| 38 | + } |
| 39 | + |
| 40 | + public function getBody() |
| 41 | + { |
| 42 | + // логика формирования письма |
| 43 | + return sprintf($this->bodyBoilerplate, $username); |
| 44 | + } |
| 45 | +} |
| 46 | + |
| 47 | +class Mailer |
| 48 | +{ |
| 49 | + public function send(Mail $mail) |
| 50 | + { |
| 51 | + mail($mail->getMailTo(), $mail->getSubject(), $mail->getBody()); |
| 52 | + } |
| 53 | +} |
| 54 | +``` |
| 55 | + |
| 56 | +При помощи такого разделения `Mailer` отвечает только за отправку, но не отвечает за отправляемое, а `Mail` наоборот. |
| 57 | +То есть изменив логику формирования письма это никак не повлияет на его отправку и наоборот, если есть необходимость поменять способ отправки не нужно будет задумываться еще и формировании его содержимого. |
| 58 | + |
| 59 | +### Information Expert |
| 60 | + |
| 61 | +Information Expert - этот принцип говорит нам, что кто владеет данными, тот и должен по логике ими управлять. |
| 62 | + |
| 63 | +```php |
| 64 | +class BillProduct { |
| 65 | + private int $quantity; |
| 66 | + |
| 67 | + private float $price; |
| 68 | + |
| 69 | + public function getSum(): float |
| 70 | + { |
| 71 | + return $this->quantity * $this->price; |
| 72 | + } |
| 73 | +} |
| 74 | + |
| 75 | +class Bill { |
| 76 | + private array $billProducts = []; |
| 77 | + |
| 78 | + public function addBillProduct(BillProduct $billProduct): void |
| 79 | + { |
| 80 | + $this->billProducts[] = $billProduct; |
| 81 | + } |
| 82 | + |
| 83 | + public function getSum() |
| 84 | + { |
| 85 | + $totalSum = 0; |
| 86 | + foreach($this->billProducts as $billProduct) { |
| 87 | + $totalSum += $billProduct->getSum(); |
| 88 | + } |
| 89 | + ... |
| 90 | + } |
| 91 | +} |
| 92 | + |
| 93 | +``` |
| 94 | + |
| 95 | +Из примера видно, что у продукта из счёта есть свойства, которые позволяют рассчитать стоимость одной позиции. Значит она и должна быть рассчитана в `BillProduct`. |
| 96 | +А `Bill` оперирует уже всеми продуктами. Значит общая сумма по счету должна быть рассчитана в нем. |
0 commit comments