Который раз становлюсь наблюдателем того что в группе Новичков не совсем по уровню тему обсуждаются

Заходишь такой и тебе в лицо - "Фасады это не фасады!"

Так наши фасады != паттерн "Фасад"

Который раз становлюсь наблюдателем того что в группе Новичков не совсем по уровню тему обсуждаются

Я знаю, в контексте названия группы имею ввиду

А что нам только валидаторы и селект олл обсуждать?)

Как бы не так))

1. Док-блок с 13-й по 30-ю строки можно вынести во внешний файл, автоматом сгенерированный через ide-helper командой php artisan ide-helper:models -R -N;

2. 34-я строка не по PSR-12;

3. Метод rolesList можно в конфиг вынести;

4. Методу register вообще нечего делать в модели - это задача сервиса. Еще б валидатор туда впихнул...;

5. Метод registerByNetwork та же песня. Вдобавок, с какого перепуга модель юзера создает записи для релейшена?

6. new...

7. Методы isWait, isActive, isModerator, isAdmin, isPhoneVerified и isPhoneAuthEnabled можно превратить в атрибуты. В таком виде они могут быть извлечены вместе с моделью там, где это необходимо. Например, в SPA;

8. verify, changeRole, changeRole, unverifyPhone, requestPhoneVerification, verifyPhone, enablePhoneAuth, disablePhoneAuth, addToFavorites, removeFromFavorites,  - невооруженным глазом видны участок бизнес-логики... В МОДЕЛИ...;

В общем, это яркий пример как НЕ НАДО делать. Ни в коем случае нельзя мешать МОДЕЛЬ с БИЗНЕС-ЛОГИКОЙ, для реализации которой существуют сервисы.

Даже так, ещё лучше

> В общем, это яркий пример как НЕ НАДО делать. Ни в коем случае нельзя мешать МОДЕЛЬ с БИЗНЕС-ЛОГИКОЙ, для реализации которой существуют сервисы.

Как раз наоборот. Такой подход и называется ООП. А вы предлагаете использовать процедурное программирование.

> В общем, это яркий пример как НЕ НАДО делать. Ни в коем случае нельзя мешать МОДЕЛЬ с БИЗНЕС-ЛОГИКОЙ, для реализации которой существуют сервисы.

Как раз наоборот. Такой подход и называется ООП. А вы предлагаете использовать процедурное программирование.

Хз кто писал тот код, но человечку лучше посмотреть на работы других более опытных. Но не spatie - у него дела ещё хуже с кодом)

Что? Он наоборот предлагает ООП решение

Как бы не так))

1. Док-блок с 13-й по 30-ю строки можно вынести во внешний файл, автоматом сгенерированный через ide-helper командой php artisan ide-helper:models -R -N;

2. 34-я строка не по PSR-12;

3. Метод rolesList можно в конфиг вынести;

4. Методу register вообще нечего делать в модели - это задача сервиса. Еще б валидатор туда впихнул...;

5. Метод registerByNetwork та же песня. Вдобавок, с какого перепуга модель юзера создает записи для релейшена?

6. new...

7. Методы isWait, isActive, isModerator, isAdmin, isPhoneVerified и isPhoneAuthEnabled можно превратить в атрибуты. В таком виде они могут быть извлечены вместе с моделью там, где это необходимо. Например, в SPA;

8. verify, changeRole, changeRole, unverifyPhone, requestPhoneVerification, verifyPhone, enablePhoneAuth, disablePhoneAuth, addToFavorites, removeFromFavorites,  - невооруженным глазом видны участок бизнес-логики... В МОДЕЛИ...;

В общем, это яркий пример как НЕ НАДО делать. Ни в коем случае нельзя мешать МОДЕЛЬ с БИЗНЕС-ЛОГИКОЙ, для реализации которой существуют сервисы.

> В общем, это яркий пример как НЕ НАДО делать. Ни в коем случае нельзя мешать МОДЕЛЬ с БИЗНЕС-ЛОГИКОЙ, для реализации которой существуют сервисы.

Как раз наоборот. Такой подход и называется ООП. А вы предлагаете использовать процедурное программирование.

ООП предполагает инкапсуляцию состояния и поведения внутри самого объекта.

А ПП предлагает разделение состояния (полей структуры) и поведения (процедур).

ООП предполагает инкапсуляцию состояния и поведения внутри самого объекта

Давно?

То есть если я хочу сделать абстракцию над каким-то классом, то я буду писать логику в самом классе?