[C#] brainstorm по альтернативам множественного наследования
А может, что-то не то с архитектурой, раз такое требование появляется?
Энивей, ты предложил вполне нормальный вариант.
В зависимости от условий так же можно реализовать ТОЛЬКО класс с поддержкой А+Б, но выдавать разные интерфейсы (IA, IB, IAB).
Если важна скорость работы (не хочется лишний вызов делать) можешь генерить класс АБ автоматически.
Энивей, ты предложил вполне нормальный вариант.
В зависимости от условий так же можно реализовать ТОЛЬКО класс с поддержкой А+Б, но выдавать разные интерфейсы (IA, IB, IAB).
Если важна скорость работы (не хочется лишний вызов делать) можешь генерить класс АБ автоматически.
В C# нет множественного наследования? Что они делали последние 20 лет?
Есть в нем множественное наследование.
А в чем тогда проблема?
(Тупой ничего не понимающий Лиспер)
(Тупой ничего не понимающий Лиспер)
Чо?
Да, в шарпе нет множественного наследования классов (интерфейсы можно наследовать поскольку чуваки из Микрософта достаточно справедливо (ИМХО) решили, что разнообразные проблемы (с общим предком, например) перевешивают преимущества. Ну и опять же множественное наследование всегда можно эмулировать (аггрегацией, например) и вообще оно редко нужно.
Да, в шарпе нет множественного наследования классов (интерфейсы можно наследовать поскольку чуваки из Микрософта достаточно справедливо (ИМХО) решили, что разнообразные проблемы (с общим предком, например) перевешивают преимущества. Ну и опять же множественное наследование всегда можно эмулировать (аггрегацией, например) и вообще оно редко нужно.
Ты хотел сказать "Чуваки из Microsoft согласились с решением чуваков из Sun"? 
Нет!
Бывший чувак-из-борланда согласился сам с собой! =)
Бывший чувак-из-борланда согласился сам с собой! =)
А чем тебе интерфейсы не нравятся? 
Как все запущено...
Ну вообще у множественного наследования есть целый один б/п полезный момент - mix-in. Ну, такой паттерн где-то был. Кажется так назывался.
Он, конечно, тоже прекрасно эмулируется через аггрегацию, но всё равно не то =)
(не адд-ин а микс-ин, спосибо мадкрозу, кстати, пользуясь случаем хочу передать ему превед!)
Он, конечно, тоже прекрасно эмулируется через аггрегацию, но всё равно не то =)
(не адд-ин а микс-ин, спосибо мадкрозу, кстати, пользуясь случаем хочу передать ему превед!)
и вообще оно редко нужно.наглый пиздешь, в в системах автоматизации бизнес процессов это очень часто встречается (по моему опыту, почти в каждом проекте для бизнес-сущностей часто возникает желание иметь множественное наследование реализации.
Хм.
Мне кажется, что множественное наследование всё-таки достаточно хорошо эмулируется аггрегацией. Конечно, при этом приходится писать довольно бессмысленный код - перенаправление вызовов и всё такое. Зато есть некоторая вероятность (по-любому большая чем нулевая при автоматическом наследовании что в процессе будет задействован головной моск и отловятся возможные ошибки. И каждый раз при добавлении/изменении методов суперкласса программеру _придётся_ смотреть на код и отлавливать возможность ошибки - опять же, в отличии от случая, когда думать приходится только и исключительно компилятору, это явно плюс.
Типа, error-prone область специально ограждается невысоким заборчиком.
Если я где-то неправ, приведи пример, плиз.
Мне кажется, что множественное наследование всё-таки достаточно хорошо эмулируется аггрегацией. Конечно, при этом приходится писать довольно бессмысленный код - перенаправление вызовов и всё такое. Зато есть некоторая вероятность (по-любому большая чем нулевая при автоматическом наследовании что в процессе будет задействован головной моск и отловятся возможные ошибки. И каждый раз при добавлении/изменении методов суперкласса программеру _придётся_ смотреть на код и отлавливать возможность ошибки - опять же, в отличии от случая, когда думать приходится только и исключительно компилятору, это явно плюс.
Типа, error-prone область специально ограждается невысоким заборчиком.
Если я где-то неправ, приведи пример, плиз.
Зато в лиспе есть ахуенно полезный CLOS
Да, в целом согласен.
что в процессе будет задействован головной москвот это и раздражает жутко
Оставить комментарий
serg05
Высказываем мысли по теме:есть функциональность(набор методов и мемберов) А
есть функциональность Б
А и Б не пересекаются
Хотим классы с функциональностью А, Б, А+Б
приходит в голову только абсолютно дурацкий вариант.
релизовать классА с интерфейсом А, мемберов во внутрь
релизовать классБ с интерфейсом Б, мемберов во внутрь
для А+Б завести мемберами классА, классБ и форвардить им все вызовы от интерфейсов.
УЖОС! консюмеры моих классов пошлют меня в эротическое пешее путешествие.