ну например, когда тебе надо расширить уже существующую либу)

я так понял у Романа как раз таки такая задача и стоит

приведи пример когда нужно

Когда уже есть готовый класс и разраб не посчитал нужным его сделать абстрактым. Калькулятор доставки такой встречался . Разраб думал, что изменения ни к чему, но на деле они нам потребовались для частного случая доставки в непредусмотренное заранее местечко. Вместо дублирвоания класса просто переопределили один метод

ну хотя это наверное и плохой подход

но иначе никак)

ну понятно. единственный кеейс. как я сказал. ктото написал плохой код и надо с этим жить :)

нарушенный принцип OpenClosed

реальный класс сделан чтобы работать. а не для того чтобы его ктото наследовал и ломал всякое внутри него

SOLID не запрещает наследование

ну понятно. единственный кеейс. как я сказал. ктото написал плохой код и надо с этим жить :)

И много ли в повседневной работе встерчается первоклассного кода?)

зависит от того, кто повседневно работает )

чащ евсего прходится работать со своим кодом )

SOLID не запрещает наследование

да. но есть некий принцип Лисков. Который вообще легко нарушается чуть что. если наследовано от неабстрактного класса.

чтобы долго не писать - вот вам https://ocramius.github.io/blog/when-to-declare-classes-final/

Вооот

чувак правильно пишет

класс должен быть abstract или final

лови 5 Марко )

чувак правильно пишет

ты даже прочитать не успел ;)

)))

Просто народ думает, что надо давать как можно больше свобооды. Меньше ограничений. Но ограничения это хорошо!

правда у @chebotarevp подгорает от того что в doctrine всё final... но статья хорошая

Это не у меня, а у чела на одном из докладов на symfoniacs я видел

нарушенный принцип OpenClosed

Вы его неправильно понимаете

У них там огроменная кодовая база, и нужно было как-то им отслеживать запросы или что-то в этом роде. Из-за того что в доктрине Query был объявлен как final им пришлось лепить огроменные костылищи на тысячи строк кода.

А у меня подгорает что доктрина не может в кастомные названия индексов и fk, и в индексах не приемлет символ -

Роман, расскажи как правильно понимать

То, что класс должен быть закрыт для модификации, не означает, что вы не можете его расширить

Точно также разработчики библиотеки могут не реализовать всего необходимого мне функционала. В случае с монгой, тот же typeMap я могу захотеть задавать в рантайме. Они же предлагают создать wrapper (не предлагая интерфейсов) или пересоздавать экземпляр Collection каждый раз, что неприемлемо

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

Да иногда из-за того что некоторые свойства в библиотеке объявлены как private, получается что отрезается приличный кусок возможностей, и я иду искать более толерантную библиотеку :)

Всегда можно форкнуть

А у меня подгорает что доктрина не может в кастомные названия индексов и fk, и в индексах не приемлет символ -

PG не умеет rename index?

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

«программные сущности … должны быть открыты для расширения, но закрыты для модификации.» - добавление метода в наследнике как бы не противоричит определению.

смотря что это за сущность. Ибо все кто эту сущность юзали о твоем новом метооде знать не будут.

Open-Close вообще не сколько про классы, сколько про модули

и в двух словах - он про неизменность интерфейса модуля

более того... open-close не то, что запрещает наследование, он его в чем-то поощряет

одни абстракции. привди примр

о чем? о том, что интерфейс модуля должен быть закрыт? ;)

это ты и так знаешь.... или ты про трактование ocp?

ну когда правильное наследование по ocp

реального класса

буквально на пальцах

оно не то, что бы правильное... оно просто не про это

по мне так это самый сложный для понимания принцип из солида

оно про закрытость интерфейса и открытость поведения

а наследование - один из способов изменения поведения без изменения интерфейса

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

учитывая, что потом влез дядя боб в 96-м.... а потом, в 13-м сказал, что на самом деле это все херня, что я писал ;) https://8thlight.com/blog/uncle-bob/2013/03/08/AnOpenAndClosedCase.html

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

It should be easy to change the behavior of a module without changing the source code of that module. What it means is that you should strive to get your code into a position such that, when behavior changes in expected ways, you don't have to make sweeping changes to all the modules of the system. Ideally, you will be able to add the new behavior by adding new code, and changing little or no old code.

вот он OCP принцип... наследование тут не при чем и вполне подходит про "изменение поведения не меняя исходного кода"...

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

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

имхо

Офигенно я чат засрал ;)

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

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

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

у меня сложилось впечатление, что всё гораздо глубже - люди считают ООП === наследование

да любят это делать)

Паш, а у тебя проблема в индексах или внешних ключах?

и почему ты не можешь их просто переименовать под доктрину?

у меня сложилось впечатление, что всё гораздо глубже - люди считают ООП === наследование

о да

и почему ты не можешь их просто переименовать под доктрину?

Я уже не помню если честно, пробовал месяца 3-4 назад. Но кажется в индексах. Переименовать индекс на что-то вроде IDX_AB4FFD8X9 мне кажется не очень хорошей идеей.

гм, а не пофиг как индекс называется?

Я как раз хотел пойти от обратного, наложить доктрину как есть на текущие таблицы, потом редактировать сущности и делать diff в консоли, на основе которого генерить миграции.

ERROR: S client not available

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

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

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

Да, там впринципе все автоматом генерится. То есть доктрина влезает даже в то что в общем то ее не касается. В базе есть куча всяких легаси констрейнтов, и лучше бы их не трогать.

Ну тогда не юзай doc:mig:diff и все, синкай руками... как бы или юзаешь комбайн или руками. Иначе тебе все-равно все констрейнты придется в сущности прописывать

Да я пока отложил всю эту идею вообще. Наверно будем переезжать на phinx как придет время.

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

А то казалось бы что может быть проще чем всунуть свой вариант IndexNameGenerator.php какой-нибудь

дык пишешь свой MyPlatform и переопределяешь что нужно

типа https://github.com/doctrine/dbal/blob/2.5/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php#L1705

Но ведь я не это делаю по сути. Платформа та же mysql

Я же не пытаюсь работать с какой-то своей OurSuperDuperSql СУБД :)

ну наследуешься (о боже!) от MysqlPlatform и переопределяешь

Там кучу всего придется переопределять тогда. Там кроличья нора.

Полдоктрины доопределить копипастом ?

getCreateConstraintSQL

Да нет жи, там это так не работает. Там больше проблем. Ну или может я чего упустил.

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

к слову, я щас проверил... просто увидел по коду странное и проверил... doc:mig:diff подхватывает существующие внешние ключи и их имена

Прикольно, может это недавно добавили

вот, кстати... проблемы наследования ;) class Index extends AbstractAsset implements Constraint

И в чем тут проблема? Вроде все красиво.

мне не нравится ;)

AbstractAsset ничего не имплементирует

он просто подмешивает код для getName в разные классы, а метод getName уже требует интерфейс Constraint

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

не подскажите в чем дело

https://gyazo.com/07263ea790d48fa612ee44fdd091efd1

вероятно в неверном sql запросе, который нужно показать

Как на github'е привязать issue?

#issuenumber?