O
Clean Code:
https://laravel-news.com/clean-code-php-guide
Size: a a a
2019 September 16
AK
З цим я не згідний, в $cancellable можна поставити дефолтне значення а good виглядає як гірший варіант і створення лишнього класу при умові що MenuConfig нічого більше робити не буде
AK
З цим я не згідний, в $cancellable можна поставити дефолтне значення а good виглядає як гірший варіант і створення лишнього класу при умові що MenuConfig нічого більше робити не буде
При складнішому функціоналі таке розділення має сенс але цей упрощений приклад на мою думку лише погіршує якість і читабельність коду
O
З цим я не згідний, в $cancellable можна поставити дефолтне значення а good виглядає як гірший варіант і створення лишнього класу при умові що MenuConfig нічого більше робити не буде
в класі теж можна додати default значення
O
З цим я не згідний, в $cancellable можна поставити дефолтне значення а good виглядає як гірший варіант і створення лишнього класу при умові що MenuConfig нічого більше робити не буде
Чому зайвого? якщо ще десь треба буде такі параметри, буде дублювання, а з класом - ні (я так зрозумів)
MA
З цим я не згідний, в $cancellable можна поставити дефолтне значення а good виглядає як гірший варіант і створення лишнього класу при умові що MenuConfig нічого більше робити не буде
ну это подход с использованием DTO
AK
Чому зайвого? якщо ще десь треба буде такі параметри, буде дублювання, а з класом - ні (я так зрозумів)
З підходом я згідний в мене питання саме до прикладу оскільки він не показує в чому профіт від використання DTO
MA
З підходом я згідний в мене питання саме до прикладу оскільки він не показує в чому профіт від використання DTO
много подобного кода как примеры не показывают как и в каких ситуациях надо применять паттерны
В
Это абсолютно стандартная практика, по рефакторингу большого количества параметров - https://sourcemaking.com/refactoring/smells/long-parameter-list
Всё что здесь говорится, если много значений относяться к одному смысловому объекту, объедени их.
Всё что здесь говорится, если много значений относяться к одному смысловому объекту, объедени их.
В
Профит в том, что значения которые относятся к одной группе, объеденены, а не разбросаны по разным переменным
O
Як думаєте, перевірку чи належить користувач до проекту, варто реалізувати як правило валідації?
O
Чи, краще такі речі не робити в валідації?
O
там просто буде йти запит в бд
П
если я праивльно понимаю ларавель философию, то это должны быть или policies или gates
П
скорее gate
П
политики для моделей
AK
Як думаєте, перевірку чи належить користувач до проекту, варто реалізувати як правило валідації?
швидше до авторизації https://laravel.com/docs/6.x/validation#authorizing-form-requests
O
швидше до авторизації https://laravel.com/docs/6.x/validation#authorizing-form-requests
о, точно, дякую
П
или вообще middleware
O
Павел
политики для моделей
а, забув сказати - що це при сторені сутності, яка відноситься до проекту