randomHash()

function randomHash() { return bin2hex(openssl_random_pseudo_bytes(16)); }

если ооочень хочется можно сделать это сервисом

но тут уже надо смотреть на здравый смысл... OCP соблюден, SRP соблюдено

лично я ленивый

А что такое User ?)

почитай

и не забудь почитать в конце

Мне это напоминает сущность которая должна предоставлять доступ для работы с базой (таблицей)

почитай

Фигово читается, шея ноет, инфа не воспринимается :(

забудь про базу данных. Представь что у тебя объекты просто вечно живут в оперативке

Ну тогда лады)

может кто еще хочет подискутировать на тему SRP?

Серега, иди выпей лучше)

да я вчера уже

а то мне тренироваться объяснять эти штуки)

Сегодня тоже) Хватит о солиде

никогда не хватит о солиде)

кстати что почитать о солиде ,

??

кстати что почитать о солиде ,

Agile Software Development, Principles, Patterns, and Practices дяди боба про SOLID

Agile Software Development, Principles, Patterns, and Practices дяди боба про SOLID

спс

короч меня на большее не хватило, если захочешь можем продолжить спор и рассматривать изменения которые ты предлагаешь)

>> Хотя никто не мешает нам сделать так с самого начала. я про это и говорю, только не "никто не мешает", а "надо сразу делать", потому что пользователь не для этого. Либо название изначально выбрано некорректное

>> Хотя никто не мешает нам сделать так с самого начала. я про это и говорю, только не "никто не мешает", а "надо сразу делать", потому что пользователь не для этого. Либо название изначально выбрано некорректное

с самого начала можно сделать и так, а уже когда рефакторишь (красный - зеленый - рефакторинг) можно уже разделить.

суть в том что в типичном цикле разработки (делаем дела - рефакторим - коммитим) проверка на соответствие принципам SOLID по хорошему должна происходить вот в момент рефакторинга

проблему тут могут быть только с тем что стэп "рефакторим" у многих пропущен

а видеть "на перед" бывает далеко не так просто)

p.s. я не так много проектов видел где есть разделение User и Credentials (или похожее)

Ну хз У меня один класс который содержит бизнес логику Ну и эта модель независима в целом Там уже в контроллерах юзается так как нужно Поэтому все что с юзером - в одном классе

Ну хз У меня один класс который содержит бизнес логику Ну и эта модель независима в целом Там уже в контроллерах юзается так как нужно Поэтому все что с юзером - в одном классе

где SQL держишь?

где SQL держишь?

У меня через репозитории

Чисто делегатор для eloquent

А реализация в моделях

Чисто делегатор для eloquent

как сохраняешь связи?

я просто хз как это в eloquent организовано, я привык к unit of work

как сохраняешь связи?

Давай я тебе лучше покажу

Наглядно Так сказать

и плохо себе представляю как без UoW персистенс

Наглядно Так сказать

давай

с самого начала можно сделать и так, а уже когда рефакторишь (красный - зеленый - рефакторинг) можно уже разделить.

я так и знал, что ты меня троллишь, а не защищаешь такой подход )))) но поспорить я люблю, поэтому меня это устраивает ) вроде в "рефакторинге с использованием шаблонов" Кириевски было написано, что намного проще (если даже не лучше/правильнее) работать с кодом, где все как попало, нет ни одного шаблона и т.д., типа тогда его намного легче приводить к тому виду, который будет оптимальным на данном этапе, т.е. тот же самый "зеленый-рефакторинг" (мне самому нравится этот подход) но опять же: мне не нравится active record (не из-за srp, просто не нравится), но на работе используем его, т.е. я не всегда делаю/использую то, что мне нравится ("больной на голову шаблонами" вряд ли про меня))), и на рефакторинг у нас времени никогда нет (есть код еще из 2010, все руки не доходят, а такой код все копится и копится)

я так и знал, что ты меня троллишь, а не защищаешь такой подход )))) но поспорить я люблю, поэтому меня это устраивает ) вроде в "рефакторинге с использованием шаблонов" Кириевски было написано, что намного проще (если даже не лучше/правильнее) работать с кодом, где все как попало, нет ни одного шаблона и т.д., типа тогда его намного легче приводить к тому виду, который будет оптимальным на данном этапе, т.е. тот же самый "зеленый-рефакторинг" (мне самому нравится этот подход) но опять же: мне не нравится active record (не из-за srp, просто не нравится), но на работе используем его, т.е. я не всегда делаю/использую то, что мне нравится ("больной на голову шаблонами" вряд ли про меня))), и на рефакторинг у нас времени никогда нет (есть код еще из 2010, все руки не доходят, а такой код все копится и копится)

я на самом деле категарически против выноса логики из объектов где им самое место

> нет ни одного шаблона они так и так будут если ты принципы соблюдаешь.

> мне не нравится active record так я ж его и не юзаю) у меня честный data mapper

при active record все усложняется тем что у тебя стэйтом будет модель данных

но объектную модель ты все так же можешь делать

(опять же я так делать не пробовал, я просто по другому не предсталяю себе active record на хоть сколько нибудь большом проекте)

> и на рефакторинг у нас времени никогда нет это быстрее чем проектировать upfront придумывая миллион кейсов которых не будет. Ну то есть проектировать upfront чуть чуть да надо, но надо знать когда остановиться

а на рефакторинг время есть всегда

так же как и на тесты

это все отговорки)

потому как в сумме при рефакторинге и тестах ты за то же время сделаешь как минимум столько же

хотя ощущаться это будет "медленнее"

> мне не нравится active record так я ж его и не юзаю) у меня честный data mapper

я к тому, что "спорить" и "делать" не всегда одно и то же, в конкретном случае я бы вынес аутентификацию, но в другом месте в аналогичной ситуации я бы легко мог и в коде оставить

> (есть код еще из 2010, все руки не доходят, а такой код все копится и копится) принцип бойскаута. Есть лишних 10 минут, напиши тестик или основу для него, вынеси код в отдельный метод...

я к тому, что "спорить" и "делать" не всегда одно и то же, в конкретном случае я бы вынес аутентификацию, но в другом месте в аналогичной ситуации я бы легко мог и в коде оставить

куда бы вынес?)

я вынес в Credentials по итогу

и повторюсь - я категорически против подходов когда данные лежат отдельно от поведения

ну вот, туда бы и вынес

(с active record я просто данные воспринимаю как тупую структуру которая хранится в объекте с логикй)

ну то есть это не сервис

так как таким объектам нечего делать в контейнере с сервисами

у нас аутсорс своего приложения, кодовая база для кучи клиентов одна с небольшими изменениями, те же логины могут отличаться незначительно (кому просто логина хватит, кому с sms, а кому и гугловские коды подавай дополнительно (забыл название), поэтому либо придется кучу одинаковых user делать с разницей в аутентификации, либо сразу отдельно выносить - выбирать не приходится ))) поэтому я изначально против аутентификации в пользователе

> а кому и гугловские коды подавай дополнительно (забыл название), это все стратегии двухфакторной аутентификации

прикол в том что двухфакторную аутентификацию ты за один раз всеравно не сможешь сделать так что тебе всеравно нужен какой-то слой перед пользователем (или кредами)

и прикол в том что первый стэп двухфакторной аутентификации ничем не отличается от однофакторной

ты всеравно должен сделать сессию, просто с ограниченными правами

в application level логике я ничего плохого не вижу.

ERROR: S client not available

другой вариант - подтипы. Когда у тебя в одной таблице записи просто мэпятся на разные реализации

но это сложнее да

у меня просто текущий проект с такой же историей

есть ecom платформа и вайт лейблы

каждому подавай какой-нибудь кастом

Парни достаточно ли емкко поисано здесь отличия декоратора от прокси

Декоратор и Заместитель имеют похожие структуры, но разные назначения. Они похожи тем, что оба построены на композиции и делегировании работы другому объекту. Паттерны отличаются тем, что Заместитель сам управляет жизнью сервисного объекта, а обёртывание Декораторов контролируется клиентом.

или есть еще какие то отличия:

обычно в декоратор не передают объект которые декорируют

хотя это дело вкуса создавать экземпляр в конструкторе

имхо

декаратор просто помимо вызова основного метода может что то вызвать до и после вызова

обычно в декоратор не передают объект которые декорируют

В смысле?

там написано что заместить сам управляет жизнью объекта

а декоратор не управляет, из того что написано выше как бы можно подумать что следует

обычно в декоратор не передают объект которые декорируют

это как?

ну то есть это не декоратор, это херня какая-то

ну то есть это не декоратор, это херня какая-то

15 минут прошли?

это как?

условно можно объект что декорируешь передать в конструкторе

типо внедрение зависимостей все дела и ты такой правильный

Декоратор и Заместитель имеют похожие структуры, но разные назначения. Они похожи тем, что оба построены на композиции и делегировании работы другому объекту. Паттерны отличаются тем, что Заместитель сам управляет жизнью сервисного объекта, а обёртывание Декораторов контролируется клиентом.

да, как-то так. Прокси обычно твоим кодом выплевываются, клиентский код о них не подозревает. Пример - лэйзи инициализация сервисов.

типо внедрение зависимостей все дела и ты такой правильный

ну так это и есть оборачивание

декорируемая штука - просто еще одна зависимость декоратора

ну или он может его внутри себя создать

ну или он может его внутри себя создать

не может

теряется вся суть декоратора и вообще зачем так делать

да легко может, просто это не канонично и возможно не правильно

нет, в этом ровным счетом нет никакого смысла

но я такое видел))))

представь тест для этой херни

я согласен что получится возможно херня)

но я такое видел))))

я тоже много чего видел но просто не называй это "декорацией"