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

ну потому что в PHP это единственный способ описания объектов. А так да, для чистого ООП классы не нужны

достаточно прототипного наследования как в JS

Массивы фигачь

ну потому что в PHP это единственный способ описания объектов. А так да, для чистого ООП классы не нужны

вообще достаточно фабрик и клонирования

но в пхп методы особо не подменишь

Массивы фигачь

just give it a 5 minutes. Попробуй мыслить категорией "наследование не нужно". Представь себе ситуацию где ты бы применил наследование и подумай "а можно ли без него"

ну так

шутки ради

* с помощью композиции например

не только композиции

просто представь что у тебя нет extends, есть только implements для организации иерархии типов

Наследую модели постов и комментариев от эктиврекорда

а.... ну ты проиграл)

и прекрасно себя чувствую

а ты от DDD такой нервный

наверное...

5 лет с доктриной дают о себе знать

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

красивенький кстати в opuelence orm

да, мило

да и в целом для "поделки" ооочень качественно

просто представь что у тебя нет extends, есть только implements для организации иерархии типов

Я б повесился

единственное что бесит - венгерская нотация для интерфейсов

Я б повесился

а теперь представь что у тебя нет базы данных, active record, фреймворков и т.д.

мы же сейчас про "правильное ООП" а не про "реалии"

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

пф, с aggregate root при event sourcing надо думать как ивенты прятать)

а теперь представь что у тебя нет базы данных, active record, фреймворков и т.д.

Класс

Ничего нет

И код не надо писать

ну тебе ж надо вначале задачу бизнеса решить

Идеально

Я б повесился

ну и опять же, если мы говорим о ActiveRecord - то это, как ты говоришь - классы, тупые структуры, это не ООП"

а не фреймворк выбрать)

так что давай представим себе просто такой код

или всем, кто идет, ты кричишь с порога: "делаю только на laravel/RoR, все остальное нахер, потому что вот так вот"

final class User { /** * @var UserDataModel - Eloqent model */ private $attributes; public function __construct(string $email, sting $password) { $this->attributes->email = $email; $this->attributes->password = $password; } }

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

все счастливы

SOLID соблюдается почти

ага, ты только забыл сказать, как она туда сетится))

ага, ты только забыл сказать, как она туда сетится))

ну забыл написать new UserDataModel()

$this->attributes = new UserRowDataGateway();

при фетче - через рефлексию разумеется

че нить такое

ну тип того да

а еще можно в 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

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

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

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

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