а еще можно в UoW мапить)

угу)

Больше классов богу классов

data mapper для бедных

да нет, старый добрый row data gateway

таким как его задумывали

до этих всяких active record рубистов

если в UoW, то получится таки для бедных

почему? ты можешь спокойно делать data mapper без UoW

UoW тебе нужен тупо что бы persistance ignorance делать

хммм

ну с последним я согласен

а с первым

сегодня на собесе чувак рассказывал как он на zend2 делал через table gateway дата мэппер но без uow

ого

в смысле он случайно так сделал или намеренно?)

ну точнее не он лично... команда

ну они так решили

им мол gateway лучше было

просто у тебя в "репозиториях появляется метод update/save`

ну необязательно в репозиториях так-то

ну в гейтвее

короч не суть

ну да

он

был же ORM

passive record

там дата мэппер но без UoW

Atlas ORM или как-то так

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

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

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

ты когда-нибудь суппортил легаси проект, где все расширение функционала происходило через наследование?

Постоянно

и неужели ты не чувствуешь боли?

Нет

важно, чтобы требования менялись

а ты работал с проектами где было подругому?

да

а ты работал с проектами где было подругому?

Нет)

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

Ну да

тесты я так понимаю ты не пишешь, потому забудем о них

Почему же

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

Нет, слежу за этим

Ну да

то есть, боль таки есть?

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

или ты во всем винишь "авторов изменений"?

Нет, слежу за этим

как так то? А баги кто фиксит?

Никого не виню, принимаю как естественный процесс мироздания

Нет, слежу за этим

а сколько SLOC в проекте? Именно вашего кода, который поддерживаете, а не 3rd

Баги и костыли всегда были и будут независимо от модели разработки

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

Баги и костыли всегда были и будут независимо от модели разработки

да, так и есть. Вопрос в том, как минимизировать ущщерб

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

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

тот же Yii как пример)

а если требования меняются часто? Или ты понятия не имеешь на данный момент что на что влияет, то нужно вводить избыточность, дробление (декомпозиция если по другому)

что бы минимизировать риски

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

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

короч

декомпозиция

разделение обязанностей

управление связанностью

все ради этого

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

Баги и костыли всегда были и будут независимо от модели разработки

хочешь задачку?

маленькую

У тебя есть классы Human, Student, Teacher.

опиши как сделать так, что бы можно было сделать студента Васю и учителя Марью Ивановну

new Human('Вася', new Strategy\Student());

да блин

ты все сломал

он знал))

я ж хотел что бы он наследование замутил(

я предположил

что бы я потом "а теперь сделай что бы Марья отчислила Васю и тот стал солдатом"

или "а теперь перенесемся в 41-ый век и преподавать будет робот"

$vasya->setStrategy(new Strategy\Soldier());

фу, setter