ну то есть что бы максимально быстро можно было бы обкатывать концепции

у меня есть на примете

что-то типа "клон инстаграма" небольшой

у тебя будет там сущности 3-4

а выборок можно нагенерить миллион и 3 базы данных для этого юзать)

ага

кстате насчет разных бд, обычно данные кэшируются в разных nosql

и тд

вот это все вместе должно сочитаться как то

ну у меня кейс сейчас, поиск идет в elasticsearch и мне просто возвращаются id-ки и я потом тупо из postgresql делаю выборку нужных данных

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

я считаю что всякие доктрины это монстры )))

но это мнение слишком радикально

я считаю что всякие доктрины это монстры )))

авторы доктрины с тобой согласы)

так же как и моя нелюбовь к наследованию среди классов (но не интерфейсов)

они сейчас активно выпиливают код из доктрины но когда случится 3-я версия пока не понятно

так же как и моя нелюбовь к наследованию среди классов (но не интерфейсов)

так тут доктринка кака раз хороша)

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

чтобы кинуть ссылку не объяснять

но хорошо что они улучшают

моя позиция совпадает с мнением авторов доктрины: - наследование хуже композиции - ставим всем классам final по дефолту - ORM нужны только для OLTP - Если вам надо сделать репорт - SQL хороший выбор

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

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

сущности без логики... flush-и в сервисах.... merge/detach выпилят и чудно

они в 3-ей доктрине будут добавлять возможность делать просто TableGateway к слову

ох пойду пилить PR для доктрины

моя позиция совпадает с мнением авторов доктрины: - наследование хуже композиции - ставим всем классам final по дефолту - ORM нужны только для OLTP - Если вам надо сделать репорт - SQL хороший выбор

Интересное мнение?

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

В большинстве случаев

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

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

по дефолту - да

Особенно родителю

есть исключения, но только 10% случаев когда наследование используется хоть сколько нибудь оправдано

а так в основном "не ну это... наследование что бы дублирование убрать"

/stat@combot

combot.org/chat/-1001071233926

/stat@combot

combot.org/chat/-1001071233926

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

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

звучит как что-то не очень хорошее

поясни свой пример

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

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

сейчас

и незабудь почитать про LSP)

Я про это говорю и это чуть ли ни в каждой либке так делают От на примере symfony, cakephp, guzzle: https://github.com/symfony/symfony/tree/master/src/Symfony/Component/Config/Definition/Exception https://github.com/cakephp/cakephp/tree/master/src/Console/Exception https://github.com/cakephp/cakephp/tree/master/src/ORM/Exception https://github.com/cakephp/cakephp/tree/master/src/View/Exception https://github.com/guzzle/guzzle/tree/master/src/Exception

Что думаете по этому поводу?

Ну или другой пример, всеми известная либка https://github.com/briannesbitt/Carbon

Что думаете по этому поводу?

эксепшены наследовать норм, там нет поведения.

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

Хотя " ставим всем классам final по дефолту" дает ответ, но не полный

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

что есть "стандартные классы"?

абстрактные классы - иногда они полезны, чаще нет.

Которые в самом пыхе

Которые в самом пыхе

а тебе часто их надо расширять?

нет конечно

абстрактные классы - иногда они полезны, чаще нет.

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

В жабке все стоновиться резко плохо, если файнал классы писать решили.

У нас как-то развитие фреймворков пошло по другому пути

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

трейты тоже ненужны

пока они не научатся имплементить интерфейсы

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

трейты тоже ненужны

Тут можно поспорить

пока они не научатся имплементить интерфейсы

хм, а ну этого не хватает, согласен

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

интерфейсы

Трейт это замена копипаста в пхп

ERROR: S client not available

интерфейсы

Много писать

Трейт это замена копипаста в пхп

именно, в них не должно быть ни грама логики

Много писать

не много

просто по другому

Так за тебя уже сделали абстракт бла-бла

Так за тебя уже сделали абстракт бла-бла

ты путаешь причину и следствие)

В котором ты только логику бизнеса написал

завтра тебе сделают интерфейс с дефолтными методами)

завтра тебе сделают интерфейс с дефолтными методами)

Они уже есть

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

Они уже есть

только public, скоро и остальное завезут

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

И их добавили, что бы именно обратную совместимость и не сломать

И их добавили, что бы именно обратную совместимость и не сломать

Посмотри при смене мажорного релиза

Они ломаются или меняются

Вы про что?

Посмотри при смене мажорного релиза

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

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

короч

А со временем жто становится ограничением

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

Это очень холиварная тема

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

НОВЫЙ код надо писать так, что бы от ваших классов не нужно было наследоваться.

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

наследование в классах обычно предполагает что... как бы он делает явно не одну маленькую штуку)

ибо иначе маленькую штуку можно было бы заменить другой маленькой штукой

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

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

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

Но наследование в интерфейсах это норм

Речь только о наследование в классах

да