From 3dc739074c11751d1039e84e73072de5d22941ed Mon Sep 17 00:00:00 2001 From: adelf Date: Mon, 23 Jan 2023 20:34:33 +0400 Subject: [PATCH] some fixes --- manuscript/1-bad-habits.md | 6 +++--- manuscript/2-di.md | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/manuscript/1-bad-habits.md b/manuscript/1-bad-habits.md index b80cbc9..077b0ae 100644 --- a/manuscript/1-bad-habits.md +++ b/manuscript/1-bad-habits.md @@ -55,11 +55,11 @@ public function store(Request $request) } ``` -Какая-то логика должна быть скопирована в **update** метод, но, например, отправка email должна быть только после создания. Код всё ещё выглядит неплохо, но количество дублированного кода растет. Еще 3-4 таких добавления и у нас будут красоваться два уже весьма больших и почти одинаковых метода **store** и **update**. Тут часто совершается ошибка - в попытке устранить дублирование кода создается метод-монстр с названием, допустим, **updateOrCreateSomething**. Этому методу нужен параметр, чтобы понимать, что он сейчас делает: "update" или "create". +Какая-то логика должна быть скопирована в **update** метод, но, например, отправка email должна быть только после создания. Код всё ещё выглядит неплохо, но количество дублированного кода растет. Еще 3-4 таких добавления и у нас будут красоваться два уже весьма больших и почти одинаковых метода **store** и **update**. Тут часто совершается ошибка - в попытке устранить дублирование кода создается метод-монстр с названием, допустим, **updateOrCreateUser**. Этому методу нужен параметр, чтобы понимать, что он сейчас делает: "update" или "create". Сразу после выделения код обычно выглядит весьма прилично, но с добавлением новых требований, особенно разных для создания и изменения сущности, разработчик начинает осознавать, что попал в капкан. В одном из проектов я видел 700-строковый метод с большим количеством `if($update)`: ```php -protected function updateOrCreateSomething(..., boolean $update) +protected function updateOrCreateUser(..., boolean $update) { if ($update)... if ($update)... @@ -69,7 +69,7 @@ protected function updateOrCreateSomething(..., boolean $update) Стоит ли говорить, что в нем частенько заводились баги, которые было трудно отлавливать в такой каше. Ошибка проста - разработчик вынес **разную** логику, которая показалась ему похожей, в один метод. Выносить в отдельный метод или класс надо всегда только одинаковую логику. Логика создания или редактирования сущности может показаться одинаковой поначалу, но почти наверняка окажется разной по мере развития проекта. -Здесь я хочу отвлечься и поговорить про naming - процесс наименования элементов языка (переменных, методов и классов). Если стараться именовать методы по смыслу, то многое можно понять уже по имени метода. **updateOrCreateSomething** - тут проблема видна без какого-либо анализа. **Or**(**Или**) это явный знак как минимум двух разных действий - двух разных логик. С развитием проекта все такие логики имеют свойство всё сильнее и сильнее отличаться друг от друга, и находиться в одном месте им совершенно противопоказано. +Здесь я хочу отвлечься и поговорить про naming - процесс наименования элементов языка (переменных, методов и классов). Если стараться именовать методы по смыслу, то многое можно понять уже по имени метода. **updateOrCreateUser** - тут проблема видна без какого-либо анализа. **Or**(**Или**) это явный знак как минимум двух разных действий - двух разных логик. С развитием проекта все такие логики имеют свойство всё сильнее и сильнее отличаться друг от друга, и находиться в одном месте им совершенно противопоказано. Надо всегда стараться называть методы, классы и переменные по смыслу. Иногда даже просто попытка назвать их хорошо может навести на хорошие мысли, которые помогут улучшить дизайн вашего кода. diff --git a/manuscript/2-di.md b/manuscript/2-di.md index e402c96..47feada 100644 --- a/manuscript/2-di.md +++ b/manuscript/2-di.md @@ -72,9 +72,9 @@ public function store(Request $request) Здесь я бы хотел остановиться и поговорить о двух важных базовых характеристиках программного кода — связность (cohesion) и связанность (coupling). Связность — это степень того, как методы одного класса (или части другой программной единицы: функции, модуля) сконцентрированы на главной цели этого класса. -Близко к SRP. +Звучит очень похоже на SRP. Связанность между двумя классами (функциями, модулями) — это степень того, как много они знают друг о друге. -Сильная связанность означает, что какие-то знания принадлежат нескольким частям кода и каждое изменения может вызвать каскад изменений в других частях приложения. +Сильная связанность означает, что какие-то знания принадлежат нескольким частям кода и каждое изменения может вызвать каскад изменений в других частях приложения. Под знаниями я имею в виду какую-нибудь логику, например знание о том, как сохранить картинку в хранилище, или как обновить поля сущности Пользователь. То же самое, что и ответственность, но под другим углом. ![](images/coupling_cohesion.png)