давай без фабрики. вот у тебя 2 класса.

пару свойств\методов

сгенерируй пожалуйста

Любые.

Вообще

ну дак сгенерируй, в чем проблема

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

или только говном поливаем?

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

Собрать муху помочь?

Рили?

+ явные примеры из всяких видов, подвидов. Насекомое, муха. ну если упрощенно

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

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

да дело не в мухах

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

Да

Он ещё требует что то описать

Собрать муху помочь?

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

Типа я шарю в мухах

Сча тебе нагуглю чот

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

а каких случаях наследование лчше композиции?

На вашу реализацию я бы тоже поглядел)

Если можно, конечно)

На вашу реализацию я бы тоже поглядел)

я бы вначале не парился и сделал бы abstract class Insect...

а уже потом думал бы

просто такое наследование "хорошее" Мухе не надо будет чтото, реализованное в этом классе. почти наверняка.

поэтому наследования реализации не будет. так что все ок

я бы вначале не парился и сделал бы abstract class Insect...

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

в отличие от господина Быстрого я не говорю что наследование плохо. я гооворю что наследование реализации плохо

когда ты наследуешь логгер, чтобы логировать :)

в отличие от господина Быстрого я не говорю что наследование плохо. я гооворю что наследование реализации плохо

а говорите, что всегда стоит предпочитать композицию наследованию?)

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

если нет, то вопросов не имею)

а говорите, что всегда стоит предпочитать композицию наследованию?)

там где это возможно. про stateless 100%

когда есть стэйт - есть уже варианты

когда есть стэйт - есть уже варианты

то есть при наличии стейта нельзя однозначно предпочитать композицию наследованию, я правильно понимаю?

но в любом случае наследовать можно только абстрактный класс

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

но в любом случае наследовать можно только абстрактный класс

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

ну там где есть стейт композировать не получится :)

полиморфизм нужен

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

ноэто так себе вариантик

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

т.е. ответтакой - если композиция возможна - надо юзать ее. и только ее :)

т.е. ответтакой - если композиция возможна - надо юзать ее. и только ее :)

класс Car, ElectroCar. Тут можно использовать композицию?)

класс Car, ElectroCar. Тут можно использовать композицию?)

а может Car это интерфейс? :)

Кар тратит топливо?)

а может Car это интерфейс? :)

аргумент

Да и вообще, что такое кар?

а может Car это интерфейс? :)

вот только как тогда общую реализацию для всех машин импелементить?)

ну мы щас о сферических машинах

давай конкретику

потому что электро кар - это может быть new Car(new ElecricEngine()) :)

потому что электро кар - это может быть new Car(new ElecricEngine()) :)

может, но тогда как раз и появится очень много проблем)

каких?

ElecricEngine implement Engine уж тут тогда

ну это ясное дело

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

и отличия не только в двигателе

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

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

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

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

чтобы бы понял. что и тут композиция возможна

я в курсе, что она возможна)

я хочу обосновать, что нельзя бездумно её выбирать вместо наследования

там, где она возможна)

давай приведи пример

да.. там будет батарейка вместо топливного бака

и если в контруктор передадут движок и бак, которые не подходят друг к другу, он выкинет эксепшен

ERROR: S client not available

ну тупо фантазирую...

новроде вполне так.. реалистично

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

да нет

он просто спросит у движка - тебе как? бак подойдет?

чуешь,как красиво получается?

генератор?

одинаковая реализация будет в ДВС и в электромобиле?

или он у нас внутри електрикэнжин будет?)

что не очень логично все-таки

разная наверно..внутри электрика он будет пустой. но ведь ничего страшного не случится если он будет обычный? :)

разная наверно..внутри электрика он будет пустой. но ведь ничего страшного не случится если он будет обычный? :)

лишняя деталь, получается?) зачем?)

Ладно, давай иначе

я запилю реализацию подобного примера с наследованием позже

а ты его декомпозируешь и побеседуем)

?

просто... онобудет сложнее

Engine - это я имел ввиду не только двидок и но и все касающеесядвижения

и кода больше, и проблем больше)

нет

не факт

KISS

не факт

99% что да)

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

задачку сделать

исделатьдвумявариантами

Фесор лайт какой то

лайт... ?

примеры более поиземленные)

ну так! они ж понятнее должны быть

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

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

ну ты это... началспорить с Быстрым, которыйсвалил. именно он тебя тупым называл.