V>Таким образом, я считаю нецелесообразным использование множественного наследования ввиду того, что в процессе развития проекта очень легко можно нарваться на трудноустранимые проблемы, связанные с множественным наследованием. То есть это как бомба замедленного действия. Я уверен, что лучше сразу потратить чуть-чуть больше усилий и воспользоваться интерфейсами, но потом спать спокойно.

Любая программная система имеет два пространства — пространство задачи и пространство решения. С моей точки зрения, множественное наследование (даже интерфейсов) — это не очень удачный инструмент для моделирования предметной области, где действительно получаются гибриды ежа с ужом. Но, с другой стороны, множественное наследование в пространстве решения, применяемое с умом, — это очень мощный и удобный инструмент, который часто позволяет сделать программу выразительнее и короче. Что-то типа

class ATL_NO_VTABLE CXyz:
    public CComObjectRootEx<CComSingleThreadModel>,
    public CComCoClass<CXyz, &CLSID_Xyz>,
    public IDispatchImpl<IXyz, &IID_IXyz, &LIBID_ATLXyzLib, 1, 0>
{
...
};

Почему множественного наследования нет в C#? Я думаю потому, что его нет в яве и объект-паскале Почему его нет в яве? Видимо, как здесь уже говорили, из-за трудностей со сборкой мусора и тем, что все классы должны наследоваться от Object, что и приводит к ромбовидному наследованию в ста процентах случаев...

Вообще, я не понимаю, почему, с точки зрения многих противников МН, одиночное наследование — допустимо? По мне, так это просто вырожденный случай, которые несет все его недостатки и достоинства. Если быть последовательным, то надо либо вообще не использовать наследование реализации, либо признать, что применяемое с умом множественное наследование ничуть не хуже одиночного.

Здравствуйте, Nikolay_Ch, Вы писали:

MS>>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету. Точнее есть, но она совсем из другой оперы.
N_C>Как это нету? А симбиоз организмов? Его можно рассматривать как некий механизм наследования.

Какой симбиоз? симбиоз — это два разных класса, "живущих" в одном namespace наследованием тут не пахнет.

Здравствуйте, minorlogic, Вы писали:

M>Мои 2 копейки в защиту множественного наследования.

M>Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

M>есть альтернативы ?

Если бы таписал еще что это значит.

Al_>Какой симбиоз? симбиоз — это два разных класса, "живущих" в одном namespace наследованием тут не пахнет.
Ну, а если рассматривать полученный организм, как один? Или один внутри другого?

Здравствуйте, Cyberax, Вы писали:

>> ИМХО, перезагрузку сигнатур ф-ий тоже стоило бы отнести к определенному
>> виду полиморфности, если считать за таковую специализацию шаблонов. Как
>> тебе?
C>Ну как бы оно тоже считается "статическим полиморфизмом".

Офигеть.

В этом случае все элементы статически-типизированных языков претендуют на статический полиморфизм.
Например:
operator+(int, int)

vdimas wrote:
> C>Ну как бы оно тоже считается "статическим полиморфизмом".
> Офигеть.
> В этом случае все элементы статически-типизированных языков претендуют
> на статический полиморфизм.
> Например:
> operator+(int, int)
Нет, не все. Язык С (и всякие там Pascal'и, и не побоюсь этого слова,
Oberon) не поддерживают перегрузку методов.

То есть:

procedure DoBlah(var a : Integer);
procedure DoBlah(var a : SomeType);
procedure DoBlah(var a : String);

такой код там невозможен.

Здравствуйте, Lloyd, Вы писали:

M>>Ромбовидное наследование для реализации базового интерфейса "интрузивный подсчет ссылок"

L>Если бы таписал еще что это значит.


----- *.h ----
class irefference_counted
{
virtual ~irefference_counted(){}
public:
virtual int add_refference() = 0;
virtual int release() = 0;
};


class imy_cool_interface : public virtual irefference_counted
{
public:
virtual int do_cool_stuff() = 0;
};

class imy_cool_interface2 : public virtual irefference_counted
{
public:
virtual int do_cool_stuff2() = 0;
};

----- *.cpp ----

class base_refference_counted : public virtual irefference_counted
{
int count;
public:
int add_refference()
{
count++;
}

int release()
{
count--;
if(!count)
delete this;
}
};


class my_cool_interface_impl : public virtual imy_cool_interface, public virtual irefference_counted
{
......
};


class my_cool_interface_impl2 : public virtual imy_cool_interface2, public virtual irefference_counted
{
......
};

Здравствуйте, Nikolay_Ch, Вы писали:

Al_>>Какой симбиоз? симбиоз — это два разных класса, "живущих" в одном namespace наследованием тут не пахнет.
N_C>Ну, а если рассматривать полученный организм, как один? Или один внутри другого?
И вот опять мы вернулись к Канту

не... я бы все равно не стал наследовать.

Здравствуйте, Кодёнок, Вы писали:

Кё>Здравствуйте, Ramzes_, Вы писали:

R_>>Интересно, а причем тут есть это в природе, или нет. Понятие искусственности/естественности метода не мало влияет на его практическую ценность. Программист он не биолог, все-таки.
Кё>вот я и говорю
Кё>во-первых, программирование, как и математика, это чисто абстрактный придуманный мир, где мы создаем такие понятия какие хотим, и отсутствие аналогов в природе никак не может быть аргументом к целесообразности использования того или иного понятия в мире абстракций.

Кё>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.
В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

Здравствуйте, McSeem2, Вы писали:

MS>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету.

Ну как же нету? Вот умирает дедушка и оставляет в наследство домик в деревне или там престол.

Здравствуйте, minorlogic, Вы писали:

M> ----- *.h ----
M>class ireference_counted
M>{
protected:
M>    virtual ~ireference_counted(){}
M>public:
M>    virtual int add_reference() = 0;
M>    virtual int release() = 0;
M>};

M>class imy_cool_interface : public virtual ireference_counted
M>{
M>public:
M>    virtual int do_cool_stuff() = 0;
M>};

M>class imy_cool_interface2 : public virtual ireference_counted
M>{
M>public:
M>    virtual int do_cool_stuff2() = 0;
M>};

template <class Base>
class ReferenceCounted : public Base
{
private:
  int refCount_;
public:
  ReferenceCounted() : refCount_(0) {}

  virtual int add_reference()
  {
    return ++refCount_;
  }

  virtual int release()
  {
    int result = --refCount_;
    if (0 == result) delete this;
    return result;
  }
};

M> ----- *.cpp ----

//M>class my_cool_interface_impl : public virtual imy_cool_interface, public virtual ireference_counted
class my_cool_interface_impl : public ReferenceCounted<imy_cool_interface>
M>{
M>......
M>};

Здравствуйте, Al_, Вы писали:

Al_>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.

Ты плохо понимаешь что сам делаешь. Программист работает не с реальным миром, а с его упрощенной моделью. Единственная неупрощенная модель мира — это сам мир.

Термины "модель", "математическая модель" тебе знакомы? Объекты модели могут сколь угодно точно отражать моделируемые сущности и отношения, но они не равняются им. И рано или поздно проявят неожиданные свойства в том или ином аспекте.

Al_>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

Не путай объекты со своим представлением о них. Они лишь могут оперировать одними и теми же терминами, похожим опытом в отношении одного и того же объекта.

Здравствуйте, Al_, Вы писали:

Кё>>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

Al_>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.
Al_>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

см. выделенное.
Обычно не программируют живую природу
Я реализую код для автоматизации работы, скажем, операциониста в банке... И что, думаешь, он оперирует понятиями "объект" или "наследование"?
Нет.
Но это не мешает удобно представить сущности с которыми он реально работает в виде объектов

Здравствуйте, Трурль, Вы писали:

MS>>Инапсуляция — да! Полиморфизм — 256 раз да! Наследование — отказать. Ибо нету такой штуки в природе, ну нету.

Т>Ну как же нету? Вот умирает дедушка и оставляет в наследство домик в деревне или там престол.

В классическом ООП-наследовании дедушка не умирает, и продолжает владеть царским престолом, хотя и передал его уже наследнику.

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

Здравствуйте, Centaur, Вы писали:

Кстати вы сами не чувстуете притиворечие ? В заголовочный файл интерфейса объекта вносится ИМПЛЕМЕНТАЦИЯ некого класаа.

То есть задача интерфейса во многом , удаление зависимостей между модулями , а внесение имплементации еще и в таком неестетичном виде , мягко говоря этой цели не соответствует .


А еслши класс имеет ОЧЕНЬ простой интерфейс и ОЧЕНЬ сложную реализацию ? на мой взгляд это противоречие.

Здравствуйте, Кодёнок, Вы писали:

Al_>>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.

Кё>Ты плохо понимаешь что сам делаешь.
Смелое заявление

Кё> Программист работает не с реальным миром, а с его упрощенной моделью. Единственная неупрощенная модель мира — это сам мир.
Кё>Термины "модель", "математическая модель" тебе знакомы? Объекты модели могут сколь угодно точно отражать моделируемые сущности и отношения, но они не равняются им. И рано или поздно проявят неожиданные свойства в том или ином аспекте.
Тут не поспоришь, но это как раз аргумент в пользу "природного" программирования

Al_>>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.
Кё>Не путай объекты со своим представлением о них. Они лишь могут оперировать одними и теми же терминами, похожим опытом в отношении одного и того же объекта.
Техническое задание приходит через призму восприятия программиста. А программист — такой же человек, он также эволюционировал на протяжении 2х млн. лет, жил одной среде. Мотыги, палки и прочий инструмент — ОНИ определяли его понимание этого мира.
Математика, кстати, тоже появилась не просто так — у человека возникла наобходимость ОЦЕНИВАТЬ те или иные ОБЪЕКТЫ, иметь возможность сравнивать их объективно.
А не так просто: вот я придумаю интеграл... пусть он делает то, то и то. НЕТ. У него есть ФИЗИЧЕСКИЙ СМЫСЛ (ты с этим термином знаком?). Любую единицу измерения наделяют ЭТИМ смыслом.
На основании задания программист строит СВОИ объекты — и не важно, что они отличаются от реальных — важно, чтобы они не отличались от того КАК их видит программист.
Так почему бы программисту не наделить физическим смыслом СВОИ объекты?

А как ты можешь их видеть, если вся твоя история прошла в этом мире, мире физики, мире природы?! ты по другому просто не можешь. У тебя нет такого опыта и быть не может.

Не понимаю зачем этому противиться?!

Здравствуйте, fmiracle, Вы писали:

F>Здравствуйте, Al_, Вы писали:

Кё>>>во-вторых, проводить аналогии с реальным миром значить ограничить сам себя, потому что в реальном мире "наследование" может иметь такие последствия, которые невозможны в вашем языке программирования, и наоборот, ваша реализация наследования в ЯП может давать такие эффекты, которых в реальном мире нет.

Al_>>Категорически не согласен. Программирование должно быть... или нет, не "должно быть", а должно иметь возможность быть тесно связанным с тем миром для которого реализуется программный код.
Al_>>В идеале программист должен оперировать теми-же объектами, что и любой другой нормальный человек. Не надо уходить от реальности.

F>см. выделенное.
F>Обычно не программируют живую природу
F>Я реализую код для автоматизации работы, скажем, операциониста в банке... И что, думаешь, он оперирует понятиями "объект" или "наследование"?
F>Нет.
Почему нет?! Ты спроси у нее. Она расскажет тебе — только другими словами. Так как это естественные понятия для человека. Здесь писали, что "наследование" — это не совсем тот термин. Я с этим согласен. Здесь будут разногласия у тебя с операционистом.
Также при желании можешь вытянуть из пользователя понятие "типа объекта" и его "экзампляра".


F>Но это не мешает удобно представить сущности с которыми он реально работает в виде объектов

AK>Вот из-за таких как вы приходится неделями разбираться в коде где ежи на велосипедах ездют, хотя ето вообще не надо. Заглядывайте почаще в ветку Архитекрура ПО, Множественное наследование — это зло.

Может, оставите свой менторский тон? Или Вы лично разбирались с моим кодом и имели к нему какие-то претензии? Я прекрасно знаю плюсы и минусы множественного наследования. Но вот таких безапеляционных заявлений претендующих на истину в последней инстанции себе не позволяю.

M>Кстати вы сами не чувстуете притиворечие ? В заголовочный файл интерфейса объекта вносится ИМПЛЕМЕНТАЦИЯ некого класаа.

Это недостаток C++ — реализацию шаблонных классов в общем случае нельзя вынести в cpp.

M>То есть задача интерфейса во многом , удаление зависимостей между модулями , а внесение имплементации еще и в таком неестетичном виде , мягко говоря этой цели не соответствует .

M>А еслши класс имеет ОЧЕНЬ простой интерфейс и ОЧЕНЬ сложную реализацию ? на мой взгляд это противоречие.

Такая ситуация обходится след. образом — делается нешаблонный класс, куда выносится вся имплементация, а уже шаблон от этого класса наследуется. Согласен, что это будет сильно смахивать на "наследование агрегацией" — поскольку каждый метод шаблона обязан будет явно вызывать метод нешаблонного класса-имплементации.