а вот ты добавил этот статический изЯблока() и Барбара уже недовольна

и что-то мне кажется, что БольшойПирог extends Пирог рано или поздно у тебя нарушит LSP

вот именно, что без статики не нарушает. а со статикой начинает нарушать

нет, статический метод не имеет отношения к использованию объекта, ибо объекта не существует

следовательно статика усиляет контракт

нет, статический метод не имеет отношения к использованию объекта, ибо объекта не существует

ну а как же тогда быть с БольшойПирог::изЯблока(): Пирог

и что?

ну он возвращает не то, что написано по смыслу

да, объекта еще нету

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

назови ::создатьПирогИзЯблока() ;)

ну так да, наверно можно

но в общем если правильно использовать наследование (т.е. почти его не использовать), то этой проблемы нет

значит именованный конструктор это не совсем конструктор, это просто фабричный метод

конструктор всегда принадлежит тому классу, где он объявлен. а "именованный конструктор" не такой

ну в общем да, конструктор у класса один ;)

т.е. называть эти штуки "именованный конструктор" неверно

вводит в заблуждение

я бы не загонялся на эту тему ;)

ну в общем да, конструктор у класса один ;)

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

я бы не загонялся на эту тему ;)

я пытаюсь нащупать какие-то паттерны вменяемого объектного дизайна на пыхе

ну в общем да, была бы перегрузка, было бы проще

но вооще мне кажется, что все сведется к ::изФруктов(ФруктовыйИнтерфейс)

чтобы избегать невалидного стейта не кучей ifов и исключений, а грамотным описанием интерфейса объекта.

интерфейса в широком смысле, т.е. конструкторы туда тоже входят

но вооще мне кажется, что все сведется к ::изФруктов(ФруктовыйИнтерфейс)

да, у меня так и получается пока

думаю как сократить цепочку new Foo(new Bar(new Baz(...)))

билдеры делать это уж краняя мера

фабрика какая-нить, хз, все от контекста зависит

вывод такой: именованные конструкторы только в final классах

довольно неочевидная связь

думаю как сократить цепочку new Foo(new Bar(new Baz(...)))

Эстетика?

Эстетика?

Скорее какое-то психическое расстройство. Задрачивать код без причин.

думаю как сократить цепочку new Foo(new Bar(new Baz(...)))

Если это VO, то можно внутри Bar создавать Baz

Если это VO, то можно внутри Bar создавать Baz

Это VO. И я примерно так и делаю.

Хотел спросить: если пользователь может быть зареган в системе несколькими способами (создание через админку, регистрация через форму, регистрация через соц. сеть), то норм ли для каждого способа делать разные комманды\сервис-методы?

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

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

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

Есть какие-либо советы?

Есть какие-либо советы?

А в чём проблема сделать один сервис и через него всё создавать, а обязательность полей проверять в том месте где приходит форма?

А в чём проблема сделать один сервис и через него всё создавать, а обязательность полей проверять в том месте где приходит форма?

Типа UserService->register(UserRegisterInput $userInput) и там уже чекать что надо, а что нет?

Типа UserService->register(UserRegisterInput $userInput) и там уже чекать что надо, а что нет?

Нет, UserRegisterInput разбирать до вызова UserService->register и вообще сделать что-то вроде UserService->register($login, $password, ...)

Нет, UserRegisterInput разбирать до вызова UserService->register и вообще сделать что-то вроде UserService->register($login, $password, ...)

Кол-во параметров может вырасти :\

Нет, UserRegisterInput разбирать до вызова UserService->register и вообще сделать что-то вроде UserService->register($login, $password, ...)

проще и удобнее запрос замэпить на какой-то объект

представляющий действие/юзкейс

представляющий действие/юзкейс

А можно краткий пример? Ну то есть, в моем случае, мне надо минимум 2 юзкейса (регистрация через форму, регистрация через админку)?

А можно краткий пример? Ну то есть, в моем случае, мне надо минимум 2 юзкейса (регистрация через форму, регистрация через админку)?

чем отличаются меджу собой действия с точки зрения данных?

по сути... в случае регистрации через админку не нужна например... активация email-а пользователя

так?

чем отличаются меджу собой действия с точки зрения данных?

При регистрации через форму, есть обязательный параметр, а с при создании с админки его нету.

по сути... в случае регистрации через админку не нужна например... активация email-а пользователя

Пока активации через почту вообще нету, но предполагаю такой юзкейс

ну просто два класса, можешь общие данные вынести в какой-то третий класс если хочешь... можешь еще как

это уже тебе решать)

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

это уже тебе решать)

Т.е., можно сделать просто как классы-команды, для каждого вида регистрации

типа того, но на самом деле все чуть сложнее конечно, ибо когда у тебя появляются такие вот расхождения в духе "что-то обязательно но это что-то уже не так обязательно если кто-то другой работает с этим же юзкейсом".

ты это в любом случае как-то выразить должен

Или один класс для регистрации и декораторы для него, если надо добавлять доп инфу для юзера

Или один класс для регистрации и декораторы для него, если надо добавлять доп инфу для юзера

да, можно так

да, можно так

Только с именнованием немного трудновато будет)))

ммм.... RegisterUser и AddUser или что-то типа того

это как по мне тот случай когда можно наплевать на правило что "класс должен именоваться существительным".

так как.... это описание процесса

ну или можно тупо суффикс добавить

ERROR: S client not available

ммм.... RegisterUser и AddUser или что-то типа того

Стоит ли передавать обязательные параметры вдля регистрации в сам метод (register(UserCredentials $userCreds, SomeParam $someParam, AnotherParam $anotherParam)) или лучше выделить VO типа UserRegisterOptions ?

Стоит ли передавать обязательные параметры вдля регистрации в сам метод (register(UserCredentials $userCreds, SomeParam $someParam, AnotherParam $anotherParam)) или лучше выделить VO типа UserRegisterOptions ?

это скорее DTO...

https://habrahabr.ru/company/mailru/blog/344696/

мдя, как это я пропустил дос на json, хех...

я, как истинный ламер, ещё и про target не знал)

я прочитал книгу Фленова "PHP глазами хакера" и сплю спокойно))

я прочитал книгу Фленова "PHP глазами хакера" и сплю спокойно))

Я читал книги Фленова. Когда они появилсь то норм, сейчас чето уже не впечатляют.

я, как истинный ламер, ещё и про target не знал)

Для меня тоже открытие

Для меня тоже открытие

чёртовы бэкэндщики)

http://www.flenov.info/

у него только по Delphi книги были более-менее, когда ещё была 7-ая версия и многие на нём писали. А потом он пошёл штамповать по всему подряд свои "*** глазами хакера"

Я читал книги Фленова. Когда они появилсь то норм, сейчас чето уже не впечатляют.

Ну у меня даже печатная книга есть дома на полке "глазами хакера". Конечно маркетинг. Я начинал с его книг. Весьма хорошо написаны. Легко читаются. Для первой книжки сойдет.

У Фелного походу где то глаза хакера лежат дома. Он ими книги пишет.

:DD

У Фелного походу где то глаза хакера лежат дома. Он ими книги пишет.

выучи функцию reply :)

для слабых в понимании и терминах ты о чём?

у телеграма есть Reply, а не только Forward

Я С++ глазами хакера читал от него, не очень как профессиональная литература, но интересная :)

@miksir под этим понимается просто ответ?)

да

@miksir под этим понимается просто ответ?)

Вот так

Я С++ глазами хакера читал от него, не очень как профессиональная литература, но интересная :)

Сто пудов про утечки памяти ?

Как правильно освободить память после закрытия файла phpexcel? Формируется штрук 30 xls файлов друг за другом, где-то на 20-х кончается память. Как побороть?

Юзать libxl. Ну или отдебажить кто ест память

Вообще инфо мало, сложно сказать как помочь. Жрать много что может.

там есть метод что-то типо phpexcel->flush() он очищает все данные, я в свое время с этим же боролся, постараюсь найти как называется точно

disconectWorksheets

/stat@combot