Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
16.12.05 16:43: Перенесено модератором из '.NET' — TK
Здравствуйте, Andrbig, Вы писали:
A>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
Да никогда оно не было нужно. Все делается с помощью интерфейсов и думаю это более прозрачно и наглядно. Вот когда интерфейсов не было может и возникла эта полемика.
Здравствуйте, снежок, Вы писали:
С>Здравствуйте, Andrbig, Вы писали:
A>>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
С>Да никогда оно не было нужно. Все делается с помощью интерфейсов и думаю это более прозрачно и наглядно. Вот когда интерфейсов не было может и возникла эта полемика.
Я повторно напомню, что подобные дискуссии не являются темой данной ветки. Прошу в данном направлении ее не развивать.
Здравствуйте, снежок, Вы писали:
С>Здравствуйте, Andrbig, Вы писали:
A>>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
С>Да никогда оно не было нужно. Все делается с помощью интерфейсов и думаю это более прозрачно и наглядно. Вот когда интерфейсов не было может и возникла эта полемика.
Даааа сильно задвинул — внушает
Очень сильно нужно именно при реализации интерфесов — миксинов когда нужна однообразная реализация для рахнотипных компонентов.
Например в нашем проекте обертки для контролов в дизайнерском режиме имеют сплошной CopyPaste
>>Например в нашем проекте обертки для контролов в дизайнерском режиме имеют сплошной CopyPaste
для чего люди придумали различные паттерны? adapter, bridge... Для того что бы мы продолжали заниматься copy/past?
Да, GUI наиболее сложно формализуемая вещь, но это не значит что каждую форму лучше лепить copy/past-ом.
Вот мне тут наставили минусов, а никто так и не объяснил для чего им множественное наследование, где они его пользовали?
Хотя может меня неправильно поняли. Есть множественное наследование интерфейсов, в сях есть множественное наследование классов. Я так понял что топик для дискусии по последнему (множ. насл. классов)
Стоит сказать что в шарпе вообще сказка, интерфейсы поддерживают не только методы, но и свойства. Ну и зачем вам после этого множественное наследование классов
>>Я повторно напомню, что подобные дискуссии не являются темой данной ветки. Прошу в данном >>направлении ее не развивать.
тема прозвучала как для чего нужно множественное наследование.
мой ответ — множественное наследование классов нигде не нужно, его возможности полностью покрывае использование интерфейсов. И чем я выбился из темы?
Здравствуйте, снежок, Вы писали:
>>>Например в нашем проекте обертки для контролов в дизайнерском режиме имеют сплошной CopyPaste С>для чего люди придумали различные паттерны? adapter, bridge... Для того что бы мы продолжали заниматься copy/past? С>Да, GUI наиболее сложно формализуемая вещь, но это не значит что каждую форму лучше лепить copy/past-ом. С>Вот мне тут наставили минусов, а никто так и не объяснил для чего им множественное наследование, где они его пользовали?
Какая нафиг форма
Есть задача обеспечить в дизайнере заданное поведение элементов управления — и как ты реализацию будеш интерфесом расширять?
Можно решить конечно предоставлением дизайнеру своего TypeDescriptor для адаптера заворачивающего нужный контрол, только, увы и ах, начинаються такие пляски с бубном .
С>Хотя может меня неправильно поняли. Есть множественное наследование интерфейсов, в сях есть множественное наследование классов. Я так понял что топик для дискусии по последнему (множ. насл. классов)
Не классов а реализации. С>Стоит сказать что в шарпе вообще сказка, интерфейсы поддерживают не только методы, но и свойства. Ну и зачем вам после этого множественное наследование классов
А затем чтобы миксин один раз написать и не парится.
например
class Base
{
public void Do() {}
}
class Mixin : IMixin
{
void IMixin.DoMixin(){;}
}
// вот тут впихиваем функционалclass C : Base, Mixin
{
}
без миксина получили бы вот такое
class C : Base, IMixin
{
void IMixin.DoMixin(){...;}
}
и теперь на уже существующию иерархии попробуй натянуть доп функционал без Copy Paste :-)
>>>Я повторно напомню, что подобные дискуссии не являются темой данной ветки. Прошу в данном >>направлении ее не развивать. С>тема прозвучала как для чего нужно множественное наследование. С>мой ответ — множественное наследование классов нигде не нужно, его возможности полностью покрывае использование интерфейсов. И чем я выбился из темы?
Приведенный выше пример показывает что это, несколько говоря, слишком сильное утверждение.
Здравствуйте, снежок, Вы писали:
С>тема прозвучала как для чего нужно множественное наследование. С>мой ответ — множественное наследование классов нигде не нужно, его возможности полностью покрывае использование интерфейсов. И чем я выбился из темы?
Я хотел узнать о примерах, а не о мнениях, хорошо это или плохо. Собсно это мнение начало дискуссию, взглянув на которую многим тему захотелось переместить в философию программирования.
А мне нафиг не нужна философия, я хотел узнать о примерах того, где множественное наследование классов помогло бы решить задачу.
>>>и теперь на уже существующию иерархии попробуй натянуть доп функционал без Copy Paste
для этого и были в C# 2.0 введены generics, как раз такого "алгоритмического наследования".
Здравствуйте, Andrbig, Вы писали:
A>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
Без множественного наследования, как и без ООП вообще, можно обойтись. Множественное наследование может упростить код, а может запутать.
abstract class Archived {
private boolean archived = false;
public void setArchived(boolean archived) {
this.archived = archived;
}
public boolean isArchived() {
return archived;
}
}
abstract class Managered {
private Manager manager = null;
public void setManager(Manager manager) {
this.manager = manager;
}
public Manager getManager() {
return manager;
}
}
abstract class PersistentWithLongId() {
private Long id = null;
public void setId(Long id) {
this.id = id;
}
public Long getId() {
return id;
}
}
class ArchivedManageredPersistentWithLongId extends Archived, Managered, PersistentWithLongId {
}
В случае с интерфейсами (без множественного наследования) прийдется наследоваться от одного класса, два других делать интерфейсами и копировать реализацию сеттеров и геттеров в ArchivedManageredPersistentWithLongId.
Здравствуйте, снежок, Вы писали:
>>>>и теперь на уже существующию иерархии попробуй натянуть доп функционал без Copy Paste С>для этого и были в C# 2.0 введены generics, как раз такого "алгоритмического наследования".
то есть ты хочеш сказать что приведеный выше пример можно записать на дженериках так?
class Base
{
public void Do() {}
}
// вот тут впихиваем функционалclass C<T> : T, IMixin
{
void IMixin.DoMixin(){;}
}
Здравствуйте, Andrbig, Вы писали:
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
Пару раз, возникало в разработке GUI. Деталей уже не помню, давно это было. Проблема заключалась в том, что был нужен компонент, ведущий себя одновременно как два стандартных примитива. Решилась инкапсуляцией обоих классов в класс-обертку.
class Base
{
protected _mixin as IMixin;
public Base(IMixin mixin)
{
_mixin = mixin;
}
public void Do() {}
}
class Mixin : IMixin
{
void IMixin.DoMixin(){;}
}
class C : Base, IMixin
{
public C(IMixin mixin) : base(mixin)
{}
void IMixin.DoMixin(){ _mixin.DoMixin;}
}
...Ei incumbit probatio, qui dicit, non qui negat...
Здравствуйте, Andrbig, Вы писали:
A>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
При использовании стратегий, они подмешиваются mixin.
Для облегчения реализации Паттерна Декоратор.
Здравствуйте, Andrbig, Вы писали:
A>Как известно, в .net нет наследования класса от нескольких родительских классов. Это является темой бурных дискуссий, которые не являются темой данной ветки.
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
Есть вот такая техника программирования. Используется в ATL. Тут наследование на агрегирование не заменишь.
template<class T> class A{
public:
void do1(){
...
static_cast<T*>(this)->action1();
...
}
};
template<class T> class B{
public:
void do2(){
...
static_cast<T*>(this)->action2();
...
}
};
class MyClass : public A<MyClass>, public B<MyClass>{
public:
void action1(){
...
}
void action2(){
...
}
};
Здравствуйте, снежок, Вы писали:
С>Да никогда оно не было нужно. Все делается с помощью интерфейсов и думаю это более прозрачно и наглядно. Вот когда интерфейсов не было может и возникла эта полемика.
Ага. И ООП тоже в общем то никогда небыло нужно. Ведь все, в общем-то, делается простым вызовм процедур. Хотя... и процедуры в общем-то не нужны. Ведь хватает просто переходов (суловных и безусловных).
В общем ни один танкист не может понять зачем нужны дороги.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, last_hardcoder, Вы писали:
_>Есть вот такая техника программирования. Используется в ATL. Тут наследование на агрегирование не заменишь.
_>
_> static_cast<T*>(this)->action1();
_>
О! Вот это изумительный пример, эмуляции ООП не ОО-средствами.
Лет 7 тому назад когда я только увидел это дело в АТЛ я тоже был в восторке. Это же почти как с примененеием интерфейсов или виртуальных методов но без оверхэда на виртуальный вызов!
Потом понял, что дурь все это. Экономия от этого стремится к нулю, а вот дизайн получается кривой.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Andrbig, Вы писали:
A>Не расскажет ли уважаемый all о примерах, когда было нужно множественное наследование? (только просьба приводить реальные примеры)
Есть одна задача — подключение реализаций к классам.
Однако у МН куча своих проблем. Вместо МН предлагаются Mix-in-ы и Traits.
Погляди вот эти ссылки
.
