Size: a a a

2020 May 01

TS

Tagil Steel in Yii Framework 2
Футуристичный Школьник
<zanuda_mode>
Альтернативой множественного наследования являются интерфейсы.
Трейты это реализация паттерна mixin
</zanuda_mode>
Интерфейсы не являются заменителями множественного наследования. Вообще. Просто семантически похожи - примерно так же как слова корока и конфета - оба на ко начинаются.
источник

OK

Oleg Kuzmenko in Yii Framework 2
Tagil Steel
Интерфейсы не являются заменителями множественного наследования. Вообще. Просто семантически похожи - примерно так же как слова корока и конфета - оба на ко начинаются.
Но интерфейсы в РНР — это единственное, где применимо множественное наследование (которого в РНР нет в принципе) 😉
источник

Д

Дмитрий in Yii Framework 2
Поведения..
источник

А

Аль Пачино in Yii Framework 2
Oleg Kuzmenko
Но интерфейсы в РНР — это единственное, где применимо множественное наследование (которого в РНР нет в принципе) 😉
Не то что в C++
источник

OK

Oleg Kuzmenko in Yii Framework 2
Дмитрий
Поведения..
Да, они решат проблему, но они выглядят не изящнее, чем нативные события
источник

TS

Tagil Steel in Yii Framework 2
Oleg Kuzmenko
Но интерфейсы в РНР — это единственное, где применимо множественное наследование (которого в РНР нет в принципе) 😉
Так вот поведения Yii, которые могут реагировать на события, наиболее близки к концепции множественного наследования.
Ведь что позволяет множественное наследование - есть у Вас класс с одним функционалом (и полями) и есть класс с другим функционалом.
Вы Наследуете кламм-наследник от этих двух классов и получаете класс, который имеет РЕАЛИЗОВАННЫМИ оба этих функционала.
Поведения пзволяют делать то же самое, конечно, в ущерб производительности
А интерфейсы - это не из этой оперы.
источник

А

Аль Пачино in Yii Framework 2
Уже не помню, каково поведение конструктора при множественном наследования.
источник

OK

Oleg Kuzmenko in Yii Framework 2
Tagil Steel
Так вот поведения Yii, которые могут реагировать на события, наиболее близки к концепции множественного наследования.
Ведь что позволяет множественное наследование - есть у Вас класс с одним функционалом (и полями) и есть класс с другим функционалом.
Вы Наследуете кламм-наследник от этих двух классов и получаете класс, который имеет РЕАЛИЗОВАННЫМИ оба этих функционала.
Поведения пзволяют делать то же самое, конечно, в ущерб производительности
А интерфейсы - это не из этой оперы.
Ну вообще не я начал про интерфейсы
источник

OK

Oleg Kuzmenko in Yii Framework 2
Просто в класс события можно в рантайме прокидывать все на свете, а если это делать на уровне поведения, то задача усложняется
источник
2020 May 02

А

Аль Пачино in Yii Framework 2
Аль Пачино
Уже не помню, каково поведение конструктора при множественном наследования.
Интересно, что будет с конструктором ?
источник

GE

Grisha Egorov in Yii Framework 2
Tagil Steel
Так вот поведения Yii, которые могут реагировать на события, наиболее близки к концепции множественного наследования.
Ведь что позволяет множественное наследование - есть у Вас класс с одним функционалом (и полями) и есть класс с другим функционалом.
Вы Наследуете кламм-наследник от этих двух классов и получаете класс, который имеет РЕАЛИЗОВАННЫМИ оба этих функционала.
Поведения пзволяют делать то же самое, конечно, в ущерб производительности
А интерфейсы - это не из этой оперы.
Не лучше в таком случае выделить функционал в отдельный сервис и прокидвывать в оба класса?
источник

А

Аль Пачино in Yii Framework 2
Grisha Egorov
Не лучше в таком случае выделить функционал в отдельный сервис и прокидвывать в оба класса?
Ну тоже надо не забывать, что чем больше объектов - больше отклика ожидать от результата .
источник

GE

Grisha Egorov in Yii Framework 2
Аль Пачино
Ну тоже надо не забывать, что чем больше объектов - больше отклика ожидать от результата .
О чем речь? Если о экономии на спичках не тот язык, если о чистом беке под бизнес логику самое то.
источник

TS

Tagil Steel in Yii Framework 2
Grisha Egorov
Не лучше в таком случае выделить функционал в отдельный сервис и прокидвывать в оба класса?
В каких-то случаях лучше, в каких-то - не очень.
В множественном наследовании ведь тоже неудобства есть.
Представьте, что будет, если у обоих предков окажутся одинаковые методы? (проблема ромбовидного наследования)
Поэтому, по моему С++ давнишнему опыту, МН помогает тогда, когда сущности достаточно простые.
Для которых сервис жирно будет делать.
источник

А

Аль Пачино in Yii Framework 2
Tagil Steel
В каких-то случаях лучше, в каких-то - не очень.
В множественном наследовании ведь тоже неудобства есть.
Представьте, что будет, если у обоих предков окажутся одинаковые методы? (проблема ромбовидного наследования)
Поэтому, по моему С++ давнишнему опыту, МН помогает тогда, когда сущности достаточно простые.
Для которых сервис жирно будет делать.
А конструктор в с++?
источник

GE

Grisha Egorov in Yii Framework 2
Tagil Steel
В каких-то случаях лучше, в каких-то - не очень.
В множественном наследовании ведь тоже неудобства есть.
Представьте, что будет, если у обоих предков окажутся одинаковые методы? (проблема ромбовидного наследования)
Поэтому, по моему С++ давнишнему опыту, МН помогает тогда, когда сущности достаточно простые.
Для которых сервис жирно будет делать.
Коллега, вы меня с кем-то спутали, я вообще против множественного наследования, я за сервисную архитектуру топлю.
источник

GE

Grisha Egorov in Yii Framework 2
Опять же когда встает вопрос производительности вы без лишней головной боли переносите севирис на другой язык без малейшей боли.
источник

А

Аль Пачино in Yii Framework 2
Grisha Egorov
Опять же когда встает вопрос производительности вы без лишней головной боли переносите севирис на другой язык без малейшей боли.
Но php быстрый язык...
источник

Д

Денис in Yii Framework 2
Аль Пачино
Но php быстрый язык...
Смотря с чем сравнивать...
источник

JT

John Travolta in Yii Framework 2
Oleg Kuzmenko
Но интерфейсы в РНР — это единственное, где применимо множественное наследование (которого в РНР нет в принципе) 😉
Только трейты, а не интерфейсы
В интерфейсах нет реализации
источник