У меня, как правило, сначала всё просто (get, add), потом код обрастает вот этими getByThisAndThat(…) , а уже потом и об архитектуре приходится думать, иначе всё превратится в месиво.
Repository - это класс, куда мы выносим какую-либо логику работы с базой данных. Чаще он используется для приложений, где есть вероятность смены базы данных.
В первую очередь это даёт нам low coupling - то, к чему мы все всегда стремимся, а уже low coupling даёт возможность сменить БД без танцев с бубном.
Согласен, да и ситуации бывают разные, но в этом и подобных примерах мы можем предположить почти наверняка что если они работают правильно по отдельности, то будут работать правильно и в цепочке. В таком случае нам после тестирования всех хендлеров скорее важно что бы они вызывались в определённом порядке.
Добавил бы Director класс который собирал бы цепочку что бы не тянуть все эти зависимости в нужный класс тем самым захламляя конструктор. Но тут конечно по обстоятельствам
Так же объявил abstract HandlerException extends Exception и его потомков для каждого хэндлера и, возможно, для каждого отдельного исключительного случая. Очень удобно, если класс исключения берёт на себя ответственность за создание сообщения, это разгружает бизнес логику.
Как мне кажется, в таком подходе плюсом является тестируемость.
Если будет один метод и в нём много условных операторов, придётся тестировать много комбинаций входных данных для одного этого метода. Так очень легко просмотреть какой-то "edge case". Тут классы достаточно простые, написать тесты для них - легчайшее занятие.
Типизированный DTO надо же тоже где-то создать, разве нет? Потому что из query string вроде приходят только строки. Как вы решаете эту проблему? (при этом я не говорю что решение из статьи мне нравится)
Так в этом не PHP виноват, а разработчики, которые не знают что ассоциативный массив кастится в [], если он пустой. Я сталкивался с такой проблемой когда только начинал знакомиться с Yii, отдавал ему данные и думал будет всё нормально. В итоге пришлось делать что-то вроде return $data === [] ? new \stdObject : $data;, что, безусловно, тоже костыль. Хорошо было бы указывать тип возвращаемого значения в аннотациях или PHPDoc
Я в статье не увидел конкретно этой идеи. Поправьте, если я не прав.
Зачем отображать блок в 15кк пикселей я могу предположить. Тут речь скорее всего не идёт об отрисовке сразу всех строк, наверное, это какой-то фикс для скрола плюс "виртульный скрол". Мол много строк и это должно отображаться на скролбаре. Пользователь должен иметь возможность потянуть его курсором мышки в любое место списка и т.д.
Если в WordPress ничего не поменялось в плане пакетных менеджеров (а я сомневаюсь), то это хорошо лишь до тех пор пока какой-то другой плагин или тема тоже не захочет использовать доктрину, тогда, как правило, возникают конфликты версий/автолоадера/чего хочешь и просто так их не решить.
В своё время мы пытались настроить перетаскивание пакета к себе в неймспейс при деплое, но от этой идеи отказались т.к. готовые инструменты работали не очень хорошо, а писать своё было долго и дорого. В итоге пакет просто заменили на самопис, благо небольшой был.
В общем, я кажется понял что @HemulGMимеет в виду.
Мы берём, создаём класс с конструктором без параметров, приватным конструктором или чем-то подобным.
Дальше определяем свойства и аргументы для них. DI, используя рефлексию, видит что надо записать в эти свойства для создания экземпляра класса.
DI создаёт все зависимости и требуемый класс и отдаёт его нам в какой-то сервис.
К слову, аргументы можно заменить на какой-то глобальный конфиг в XML, JSON, YAML, да в чём душе угодно и аргументы не понадобятся.
Моё мнение по этому поводу: такие неявные финты ни к чему хорошему не приведут, но в целом никто нам такое делать не запрещает, хотя дополнительная работа с рефлексией не вызывает восторга.
При чём тут модно/не модно? Есть терминология и люди ей пользуются. Вы же не говорите "эта штука при помощи которой ты дышишь". Вы говорите нос, лёгкие и т.д. Так и тут.
Никто вас переубедить не пытается потому что это на**р никому не надо. Уж я тем более.
Касательно класса. Там дальше давали ссылку на комментарий где в ветке говорится про стабильные и волатильные зависимости. Советую почитать. Лично я противник interface obsession, но использовать их безусловно необходимо.
Если не ошибаюсь, то это пример из каких-то тестов в США, которые проводились в середине прошлого века или около того. С месяц назад попадал на видео на эту тему.
На проекте смотрели и на ратчет и на свуле, свуле по-лучше как мне кажется. Но в итоге нам не подошла ни одна из них. Сейчас используем ASP.NET + SignalR
У меня, как правило, сначала всё просто (
get,add), потом код обрастает вот этимиgetByThisAndThat(…), а уже потом и об архитектуре приходится думать, иначе всё превратится в месиво.Я в IDE настроил шаблон, все классы теперь изначально
final:) Шаблон экономит времяНемного духоты вам в комментарии :)
Чего не
final'итеOrderDTO? От него же никто по идее не должен наследоваться. Так же, как мне кажется, код был бы чище если бы использовалось https://www.php.net/manual/en/language.oop5.decon.php#language.oop5.decon.constructor.promotionВ первую очередь это даёт нам low coupling - то, к чему мы все всегда стремимся, а уже low coupling даёт возможность сменить БД без танцев с бубном.
И я правильно понимаю что FilterDataForInsertAction это интерпретация https://refactoring.guru/ru/design-patterns/command ??
Согласен, да и ситуации бывают разные, но в этом и подобных примерах мы можем предположить почти наверняка что если они работают правильно по отдельности, то будут работать правильно и в цепочке. В таком случае нам после тестирования всех хендлеров скорее важно что бы они вызывались в определённом порядке.
Что бы я добавил:
Финализировал бы методы в
AbstractHandlerФинализировал бы всех потомков
AbstractHandlerЕстественно объявил бы тип для
$requestДобавил бы
Directorкласс который собирал бы цепочку что бы не тянуть все эти зависимости в нужный класс тем самым захламляя конструктор. Но тут конечно по обстоятельствамТак же объявил
abstract HandlerException extends Exceptionи его потомков для каждого хэндлера и, возможно, для каждого отдельного исключительного случая. Очень удобно, если класс исключения берёт на себя ответственность за создание сообщения, это разгружает бизнес логику.Как мне кажется, в таком подходе плюсом является тестируемость.
Если будет один метод и в нём много условных операторов, придётся тестировать много комбинаций входных данных для одного этого метода. Так очень легко просмотреть какой-то "edge case". Тут классы достаточно простые, написать тесты для них - легчайшее занятие.
Типизированный DTO надо же тоже где-то создать, разве нет? Потому что из query string вроде приходят только строки. Как вы решаете эту проблему? (при этом я не говорю что решение из статьи мне нравится)
Предлагаете всё писать руками?
Так в этом не PHP виноват, а разработчики, которые не знают что ассоциативный массив кастится в
[], если он пустой. Я сталкивался с такой проблемой когда только начинал знакомиться с Yii, отдавал ему данные и думал будет всё нормально. В итоге пришлось делать что-то вродеreturn $data === [] ? new \stdObject : $data;, что, безусловно, тоже костыль. Хорошо было бы указывать тип возвращаемого значения в аннотациях или PHPDocЯ в статье не увидел конкретно этой идеи. Поправьте, если я не прав.
Зачем отображать блок в 15кк пикселей я могу предположить. Тут речь скорее всего не идёт об отрисовке сразу всех строк, наверное, это какой-то фикс для скрола плюс "виртульный скрол". Мол много строк и это должно отображаться на скролбаре. Пользователь должен иметь возможность потянуть его курсором мышки в любое место списка и т.д.
Если в WordPress ничего не поменялось в плане пакетных менеджеров (а я сомневаюсь), то это хорошо лишь до тех пор пока какой-то другой плагин или тема тоже не захочет использовать доктрину, тогда, как правило, возникают конфликты версий/автолоадера/чего хочешь и просто так их не решить.
В своё время мы пытались настроить перетаскивание пакета к себе в неймспейс при деплое, но от этой идеи отказались т.к. готовые инструменты работали не очень хорошо, а писать своё было долго и дорого. В итоге пакет просто заменили на самопис, благо небольшой был.
Есть ли у вас решение для подобных проблем?
В общем, я кажется понял что @HemulGMимеет в виду.
Мы берём, создаём класс с конструктором без параметров, приватным конструктором или чем-то подобным.
Дальше определяем свойства и аргументы для них. DI, используя рефлексию, видит что надо записать в эти свойства для создания экземпляра класса.
DI создаёт все зависимости и требуемый класс и отдаёт его нам в какой-то сервис.
К слову, аргументы можно заменить на какой-то глобальный конфиг в XML, JSON, YAML, да в чём душе угодно и аргументы не понадобятся.
Моё мнение по этому поводу: такие неявные финты ни к чему хорошему не приведут, но в целом никто нам такое делать не запрещает, хотя дополнительная работа с рефлексией не вызывает восторга.
Можно безусловно, но нужно ли? Вот тут вопрос.
Это что за зверь такой? В смысле язык, раньше не встречал как будто бы.
И как в protected поля попадают данные? Через рефлексию?
Что за скрытая агрессия не понимаю.
При чём тут модно/не модно? Есть терминология и люди ей пользуются. Вы же не говорите "эта штука при помощи которой ты дышишь". Вы говорите нос, лёгкие и т.д. Так и тут.
Никто вас переубедить не пытается потому что это на**р никому не надо. Уж я тем более.
Касательно класса. Там дальше давали ссылку на комментарий где в ветке говорится про стабильные и волатильные зависимости. Советую почитать. Лично я противник interface obsession, но использовать их безусловно необходимо.
И помните, только ситхи всё возводят в абсолют.
Интерфейс нужен что бы определить контракт. Не понимаю как фраза "сидит в своём файле" могла вызвать вопрос "зачем он нужен?"
Если не ошибаюсь, то это пример из каких-то тестов в США, которые проводились в середине прошлого века или около того. С месяц назад попадал на видео на эту тему.
Подобная статья уже была, не могу найти через поиск, но я в этом абсолютно уверен
Я не думаю что стоит обращать внимание на комментарий человека у которого 2 из 4 статей на хабре про JS. Ещё про РНРшников что-то пишет...
А с вами согласен, десктоп это вообще не о РНР имхо
На проекте смотрели и на ратчет и на свуле, свуле по-лучше как мне кажется. Но в итоге нам не подошла ни одна из них. Сейчас используем ASP.NET + SignalR