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

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

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

абстрактные менеджеры?

Ну да или контроллеры

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

Shape{ AcceptVisitor(IVisitor visitor); } Circle is a Shape { AcceptVisitor(IVisitor visitor){ visitor.AcceptCircle(this); } } Drawer is a IVisitor{ AcceptCircle(Circle circle); AcceptSquare(Square square); }

По моему это и есть реализация визитора?

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

По моему это и есть реализация визитора?

А я не говорил что это не она

Или ты хотел пример того, как я решил сделать?

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

Я не делал реализацию через визитера

Я по другому пути решил пойти

Или ты хотел пример того, как я решил сделать?

Да.

Ну или суть.

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

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

Завтра с рабочего места опишу. Но общая суть в том, что я пересмотрел иеерархию и разделил ответсвенности таким образом, что отпала надобность в проверке типов

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

Мне проникнуться композицией сложнее было

Это мое субъективное мнение, если логика классов наследников проста и сам родитель прост как три копейки считаю можно наследование использовать, ещё аргумент, наследование понимает больший процент новичков

По поводу аргумента про новичков. Вот в чём причина - это вопрос. В том ли что наследование проще? Может быть. А может быть в том, что люди начинают взаимодействие объектов с наследования (в конце концов оно есть в тройке инкапсуляции, наследования, полиморфизма, да и чаще всего есть чётко выраженные в языке вещи часто типа extends) изучать.

По поводу аргумента про новичков. Вот в чём причина - это вопрос. В том ли что наследование проще? Может быть. А может быть в том, что люди начинают взаимодействие объектов с наследования (в конце концов оно есть в тройке инкапсуляции, наследования, полиморфизма, да и чаще всего есть чётко выраженные в языке вещи часто типа extends) изучать.

До этих трёх ещё находится абстракция, а она подталкивает к композиции. Но это ещё от трактовки зависеть может

Как новичок ,не зная магических методов , декоратор построит?

По поводу аргумента про новичков. Вот в чём причина - это вопрос. В том ли что наследование проще? Может быть. А может быть в том, что люди начинают взаимодействие объектов с наследования (в конце концов оно есть в тройке инкапсуляции, наследования, полиморфизма, да и чаще всего есть чётко выраженные в языке вещи часто типа extends) изучать.

Да, я о том же

Как новичок ,не зная магических методов , декоратор построит?

композиция не подразумевает декоратор

Как новичок ,не зная магических методов , декоратор построит?

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

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

а в большинстве случаев это именно то, что хотят услышать собеседующие. Я обычно сам уточнял "Вы хотите чтобы я рассказал про инкапсуляцию, наследование, полиморфизм?" и в 100% случаев люди кивали головами.

Как новичок ,не зная магических методов , декоратор построит?

а нафиг магические методы в декораторе? о_О Не, ну так можно сказать и "Как новичёк, не зная рефлекшен апи декоратор построит?"?

а нафиг магические методы в декораторе? о_О Не, ну так можно сказать и "Как новичёк, не зная рефлекшен апи декоратор построит?"?

всякие __call, думаю

а нафиг магические методы в декораторе? о_О Не, ну так можно сказать и "Как новичёк, не зная рефлекшен апи декоратор построит?"?

Чтобы использовать __call __set и ТД, чтобы не описывать методы самого оборачиваемого обьекта

Мне проникнуться композицией сложнее было

ну то есть опять же - ты судишь по себе. Выборка не репрезентативна. НАследование простое но это лишь самообман что ты понимаешь его

Чтобы использовать __call __set и ТД, чтобы не описывать методы самого оборачиваемого обьекта

ясно понятно

ясно понятно

))))

я начал подозревать что что-то не то когда ты заговорил про php 5.6

Чтобы использовать __call __set и ТД, чтобы не описывать методы самого оборачиваемого обьекта

ну это же не обязательное условие реализации декоратора =\

тут уже 7.3 выйдет через пару недель

ну это же не обязательное условие реализации декоратора =\

Нет

Можно руками проксировать все методы

ну это же не обязательное условие реализации декоратора =\

это вообще к декораторам не имеет никакого отношение. Но соглашусь что если бы было как в Kotlin с их delegate - было бы клево

но пыху до этого как до луны

Можно руками проксировать все методы

https://kotlinlang.org/docs/reference/delegation.html - а если так?

Можно руками проксировать все методы

вообще там не должно быть много методов)

но повторюсь - так как в котлине оно намного интереснее конечно...

вообще там не должно быть много методов)

Согласен

В общем со всем согласен

Но наследование проще понять)))

не экстраполируй свой опыт на всех

не экстраполируй свой опыт на всех

Ок

Можно сказать что в Go наследование сделано через композицию?

Действительно многое зависит от языка

Можно сказать что в Go наследование сделано через композицию?

там же структурный тайпинг, там круче

Как то не полумал

пых вообще хуевый язык, мерять по ним концепты из компьютер сайнс... ну такое

там же структурный тайпинг, там круче

Что такое структурный тайпинг? Не загуглилось.

Что такое структурный тайпинг? Не загуглилось.

https://en.wikipedia.org/wiki/Structural_type_system - там справа еще полезные ссылки на другие варианты систем типов

типа Duck Typing, manifest vs inferred, nominal vs structural,

пых вообще хуевый язык, мерять по ним концепты из компьютер сайнс... ну такое

всем срочно переходить на js? ^_^

всем срочно переходить на js? ^_^

ммм... typescript я бы еще понял)

или там если js то с flow

а просто js - опасна

ну и скорее я о том что бы потыкать еще пару тройку языков

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

нет, у меня на работе только php и js и больше я ни о чём представления не имею, так что методом исключения остаётся только js, только хардкор!

Чтобы использовать __call __set и ТД, чтобы не описывать методы самого оборачиваемого обьекта

разве декоратор не должен имплементить тот же интерфейс, который и оборачиваемый объект?

разве декоратор не должен имплементить тот же интерфейс, который и оборачиваемый объект?

ему впадлу проксировать методы которые он не декорирует.

nuff said, лень не всегда двигатель прогресса.. это такая, недальновидная лень

нет, у меня на работе только php и js и больше я ни о чём представления не имею, так что методом исключения остаётся только js, только хардкор!

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

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

Я мало пишу на js. Эти инструменты это для функционального стиля больше, верно?

разве декоратор не должен имплементить тот же интерфейс, который и оборачиваемый объект?

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

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

Абстрактный класс разве не формирует интерфейс?

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

И как вы тогда его декарировать собираетесь?

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

И как вы тогда его декарировать собираетесь?

Не его, а его наследников

Как вы будете декарировать его наследников? Можете пример привести?

Для частичной реализации абстракции

Я тоже себе этот вопрос задал)) и мой ответ совпадает с ответом романа, для избежания дублирования кода и методов

Что функции?

И где эту функцию разместить? В глобальном прострастве?

Функция не метод

Вполне возможно что подъехали ФП'шники. Не совсем ещё понимаю кто тут в какой грех подался :(

Я тоже себе этот вопрос задал)) и мой ответ совпадает с ответом романа, для избежания дублирования кода и методов

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

Мне сложно понимать обрывистые реплики, пожалуйста объясни контекст для недалёких :(

Это был как пример, что может не быть интерфейса вовсе , конечно случай не совсем правильный

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

Это был как пример, что может не быть интерфейса вовсе , конечно случай не совсем правильный

Интерфейс у тебя всегда есть, он может быть не выражен формально, но он есть