Последнее предупреждение, завязывай с оффтопом.

Про зарплаты потёрли?

Про зарплаты потёрли?

конечно) тупиковая тема

а тему вообще развивать начали?

или Фарт расчехлил банхаммер раньше?

или Фарт расчехлил банхаммер раньше?

Да не знаю. Просто вспомнил и решил сообщение удалить. Смотрю, а тут пусто) На счёт банхаммера не скажу.

зарплаты с ООП слабо коррелируются )

зарплаты с ООП слабо коррелируются )

умеешь ооп - получи 150+; не умеешь - 40)

так

прекращайте

давайте еще немного побеседуем про srp вообще и информационного эксперта в частности вот есть у меня один класс, который занимается тем, что считает периоды по датам делает одну важную штуку и две вспомогательных важная: получает на вход дату начала и конца периода и тип (P1M/P3M/P1Y) (P3M для кварталов) отдает на выход массив периодов из двух дат и float коэффициента, который показывает, насколько этот период "полный" (период с 15 по 30 апреля - это коэф. 0.5) вспомогательные: колво дней между двумя датами и колво дней в периоде по его стартовой дате и типу периода сейчас это дело явно нарушает SRP с другой стороны - information expert вроде бы вполне на месте (т.к. в этом классе содержится инфа о кварталах и прочее) кто как разрешил бы такую ситуацию? мои варианты: - статические методы - фигня, проблемы не решает - бить на классы - ну тоже не очень - трейты - дублирование кода

отдает на выход массив периодов из двух дат и float - я уже тут не понял...это один метод возвращает что ли всё сразу?

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

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

изменения то такое просто сейчас везде, где мне нужен этот функционал - я создаю объект new PeriodCalculator() и дальше работаю с ним

если ты где-то используешь эти вспомогательные функции еще, отдельно от PeriodCalculator , то имеет смысл вынести их в отдельную сущность. а так, это вплоне могут быть private методы калькулятора, которые помогают ему там что-то считать

отдает на выход массив периодов из двух дат и float - я уже тут не понял...это один метод возвращает что ли всё сразу?

да, тоже костыльная штука оптимально было бы класть на какую-то dto, но на тот момент времени не было

мне кажется: две даты и флоат - это сущность Period

ну, я так думаю

первая вспомогательная - используется и в калькуляторе, и отдельно, вторая используется отдельно

мне кажется: две даты и флоат - это сущность Period

вернее это VO

а твой калькулятор уже возвращает массив VO

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

первая вспомогательная - используется и в калькуляторе, и отдельно, вторая используется отдельно

тогда уже имеет смысл подумать над их вынесением в отдельный класс

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

создай класс CalculatorConstant, общий для всех

окей, с этим в принципе согласен делать ли эти классы сугубо статическими?

стейта и зависимостей на данный момент у них нет

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

насчет статики сам не знаю )

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

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

но вообще хотелось бы услышать на этот счет еще мнений. когда уместно юзать трейты и статику

в трейтах меня смущает то, что под капотом - это копипаст

в трейтах меня смущает то, что под капотом - это копипаст

не понял тебя? наоборот же типо ты туда засовываешь кусок кода и юзаешь его везде )

или на уровне интерпретатора

ну да) но фактически php тупо копипастит то, что в трейте, в сам класс

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

Мне кажется здесь статика будет уместна - я не брезгую статикой когда мне нужно выполнять какие-то общие операции над какими то примитивными VO. Т.е те классы которы в теории могли бы быть частью стандратной библиотеки языка. Конечно можно вынести всё в MyDateFormatSevice и его инджектить всюду но хз

сервис не катит - не буду ведь я его в сущности инжектить

тогда я за статику +

но вообще хотелось бы услышать на этот счет еще мнений. когда уместно юзать трейты и статику

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

окей, спасибо

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

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

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

можно и не знать всяких страшных слов))

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

давайте еще немного побеседуем про srp вообще и информационного эксперта в частности вот есть у меня один класс, который занимается тем, что считает периоды по датам делает одну важную штуку и две вспомогательных важная: получает на вход дату начала и конца периода и тип (P1M/P3M/P1Y) (P3M для кварталов) отдает на выход массив периодов из двух дат и float коэффициента, который показывает, насколько этот период "полный" (период с 15 по 30 апреля - это коэф. 0.5) вспомогательные: колво дней между двумя датами и колво дней в периоде по его стартовой дате и типу периода сейчас это дело явно нарушает SRP с другой стороны - information expert вроде бы вполне на месте (т.к. в этом классе содержится инфа о кварталах и прочее) кто как разрешил бы такую ситуацию? мои варианты: - статические методы - фигня, проблемы не решает - бить на классы - ну тоже не очень - трейты - дублирование кода

Хотя если подумать, можно создать иммутабельный VO Period. Который в конструкторе будет принимать даты, и уже у созданного периода можно получать будет разную инфу - полноту, число дней(недель, месяцев и т.д)

да наверно я бы так сделал! вы просто попытались меня запутать со своей статикой и терйтами и я поддался)

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

Хотя если подумать, можно создать иммутабельный VO Period. Который в конструкторе будет принимать даты, и уже у созданного периода можно получать будет разную инфу - полноту, число дней(недель, месяцев и т.д)

с таким же успехом можно и сервис сделать, не?

тут зависит от потребностей

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

с таким же успехом можно и сервис сделать, не?

нет, тут у нас нормлаьный объект со своей логикой

а сервис это та же статика будет в этой ситуации

это относится к родительской сущности (периодичность инвойсинга)

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

так а зачем ему это знать? просто методы типа getDayInPeriod() getSecondInperiod()

или getTimePartInPeriod($timePeriodName) - неудачный нейминг но идея понятная

а потому, что у меня в моем классе из опмессаги есть метод getPeriods(\DateTime $startDate, \DateTime $endDate, string $type)

и в type заходит P1M/P1Q(который по сути P3M)/P1Y

нет, тут у нас нормлаьный объект со своей логикой

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

ERROR: S client not available

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

сервис будет только логикой)

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

нет это просто будет набор функций, который получают данные и возвращают данные, но завернутый в объект)

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

P1M - это месяц? а P1Q - это квартал?

ага

DateInterval под капотом был изначально

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

ну не знаю насчет этого...по сути он же обладает всей информацией необзходимой для подсчета

не обладает, если он не знает partition type

ага

а это названия объектов же, не классов?

а это названия объектов же, не классов?

P1M? нет, просто спека DateInterval

эти названия нигде не применяются

не так выразился

не обладает, если он не знает partition type

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

нет это просто будет набор функций, который получают данные и возвращают данные, но завернутый в объект)

ты про сервис в контексте DDD говоришь ? )

есть договор, в нем есть настройка — периодичность инвойсинга в базе она хранится именно теми P** записями

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

число дней - да

но мне нужно знать коэффициент "полноты" периода

т.к. потом по нему будет корректироваться сумма инвойса

более того, кварталы - фиксированные во времени штуки

то есть период с началом 1 марта и окончанием 31 марта будет иметь коэффициент 1, если инвойсинг по месяцам идет и коэффициент около 0.33 - если по кварталам

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

@fes0r как появишься - подскажи, пожалуйста: при композиции сущностей ты в композите делаешь геттер на вложенную сущность или пробрасываешь геттеры до необходимых полей?

@fes0r как появишься - подскажи, пожалуйста: при композиции сущностей ты в композите делаешь геттер на вложенную сущность или пробрасываешь геттеры до необходимых полей?

ммм.... если у тебя появляются такие штуки то стоит задуматься нужны ли тебе они

согласен, вопрос туповат в итоге сделал без проброса

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

а еще есть способность закрыть на это все глаза и сделать фичу)

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