S>Нет, нет, делать их синглтонами — это значит что других таких Васи и Пети больше не существует!
S>Ведь ничто не запрещает сделать синглтоном Машу и Колю...
Сначала я тоже так подумал, но вот куда девать клонирование... Если верить ученым при этом появляется особь, полностью идентичная своему "родителю"...

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

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

MF>>Делать их синглтонами — все равно, что сказать, что кроме Васи и Пети больше Человеков не существует.
S>Нет, нет, делать их синглтонами — это значит что других таких Васи и Пети больше не существует!
S>Ведь ничто не запрещает сделать синглтоном Машу и Колю...

Это похоже на обфускацию ручной работы
Все знают, что Вась, Петь, Маш и Коль на свете много и данная модель не соответствует действительности.
Хотя если все супер, а порефакторить ну хоть что-нибудь все же хочется, это неплохой заклад на будущее.

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

B>....
B>class Растение
B>class Фрукт_Овощь:Растение
B>class Цветок: Растение

B>Последние два класса законченны и содержат поля.

B>Тогда
B>class Морковь:Овошь

B>И вот оно !!:
B>class Вишня:Цветок,Фрукт_Овошь
B>В роде бы всё сходиться, но реализовать такое нельзя.
B>Вишня "это есть" и цветок и фрукты_овошь.

B>Являеться ли всё выше изложенное таковым или стоит плесать в аналогичных случаях в разных похожих примерах из разных областей от:
B>У кого-то,тот кто будет возможно доказывать, что это не так, вишня будет ассоциироваться с одним, а у кого-то со вторым и по теории тогда можно просто поступить так:

B>class Дерево
B>class Вишня:Дерево
B>{ в полях реализовать отношение "has a" для цвета и плода }

B>Но это смахивает на подгонку правильного подхода к тому, что позволяет язык С# ?


Но вишня одновременно не может одновременно цвести и давать фрукты!!! поэтому наследование реализации не корректно, что вы и доказали

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

_>>Однако Вам ни кто не мешает использовать композицию классов. И вообще множественное наследование очень трудно для восприятия.

V>Чем труднее МН интерфейсов?

Спецэффектами.

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

V>В нединамических языках полиморфизм только через наследование и бывает.

Для полиморфизма нужно наследование только контракта. Наследовать для этого реализацию совсем не обязательно.

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

R_>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность.

Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.

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

V>>В нединамических языках полиморфизм только через наследование и бывает.

AVK>Для полиморфизма нужно наследование только контракта. Наследовать для этого реализацию совсем не обязательно.

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

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

V>Тут как-то уже обсуждали, что было бы неплохо ввести в дотнет такую сущность как контракт в чистом виде.

Она там уже есть.

V> А пока что интерфейс в дотнет — это навроде чисто-виртуального базового класса из С++ с виртуальным наследованием, со всеми присущими ограничениями.

Нет, это ООП контракт в чистом виде. Собственно, ради этого его и придумали. А то, что в С++ вместо контракта как первоклассной сущности используются абстрактные классы, так это проблема С++.

V> И называние всего этого дела "реализацией интерфейсов" вместо "наследования" — это скорее вопрос идеологического плана...

А в этом топике вобще то и обсуждается вопрос идеологического плана.

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

B>....
B>class Растение
B>class Фрукт_Овощь:Растение
B>class Цветок: Растение

B>Последние два класса законченны и содержат поля.

B>Тогда
B>class Морковь:Овошь

B>И вот оно !!:
B>class Вишня:Цветок,Фрукт_Овошь
B>В роде бы всё сходиться, но реализовать такое нельзя.
B>Вишня "это есть" и цветок и фрукты_овошь.


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

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

MS>Традиционно под наследованием понимается, что-то типа "производный класс делает все то же самое, что и базовый и плюс к тому, еще это, это и вот это". На мой взгляд, это и есть самое неправильное использование наследования. Во всяком случае, ни к чему хорошему оно никогда не приводило — получался слошной бардак и рак головы. Особенно умиляют попытки порождать производные классы от чего-то типа std::vector.

MS>Правильное использование наследования — это замещение (override) виртуальных функций. Только оно и ничего более. От этого есть безусловная польза, но это уже становится не наследованием, а специализацией. Поэтому я и говорю, что наследование как таковое является сомнительной концепцией. Какая-то она грязноватая эта концепция, с намешанными в одну кучу разными понятиями.


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

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

B>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
B>Зачем убрали возможность public/protected/private наследования даже в одиночном.
B>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
B>Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

1) Со множественным наследованием есть проблемы (например Diamond problem). Так как если использовать его без меры граф наследования становится запутанным и становится трудно понять что к чему. Так же могут появится и циклические ссылки, отсюда непонятки с порядком вызова конструкторов,
дополнительный геморрой с виртуальным наследованием и т. п.

2) Технические проблемы с реализацией в среде со сборкой мусора.

Дело в том, что для объекта со множеством предков приведение к базовому классу может означать получение указателя на адрес внутри класса:

вот выдержка из S.Lippman "Inside the C++ Object model", раздел 3.4
(надеюсь меня не убьют за цитирование копирайченного материала ) :

Multiple inheritance is neither as well behaved nor as easily modeled as single inheritance. The complexity of multiple inheritance lies in the "unnatural" relationship of the derived class with its second and subsequent base class subobjects. Consider, for example, the following multiply derived class, Vertex3d:

class Point2d { 
public: 
   // ... 
protected: 
   float _x, _y; 
}; 

class Vertex { 
public: 
   // ... 
protected: 
   Vertex *next; 
}; 

class Vertex2d : 
   public Point2d, public Vertex { 
public: 
   //... 
protected: 
   float mumble; 
};

The problem of multiple inheritance primarily affects conversions between the derived and second or subsequent base class objects, either directly

extern void mumble( const Vertex& ); 
Vertex3d v; 
... 
// conversion of a Vertex3d to Vertex is ``unnatural'' 
mumble( v );

or through support for the virtual function mechanism. The problems with supporting virtual function invocation are discussed in Section 4.2.

The assignment of the address of a multiply derived object to a pointer of its leftmost (that is, first) base class is the same as that for single inheritance, since both point to the same beginning address. The cost is simply the assignment of that address (Figure 3.4 shows the multiple inheritance layout). The assignment of the address of a second or subsequent base class, however, requires that that address be modified by the addition (or subtraction in the case of a downcast) of the size of the intervening base class subobject(s). For example, with


Figure 3.4. Data Layout: Multiple Inheritance

Vertex3d v3d; 
Vertex  *pv; 
Point2d *pp; 
Point3d *p3d;

the assignment

pv = &v3d;

requires a conversion of the form

// Pseudo C++ Code 
pv = (Vertex*)(((char*)&v3d) + sizeof( Point3d ));

whereas the assignments

pp  = &v3d; 
p3d = &v3d;

both simply require a copying of the address. With

Vertex3d *p3d; 
Vertex   *pv;

the assignment

pv = p3d;

cannot simply be converted into

// Pseudo C++ Code 
pv = (Vertex*)((char*)p3d) + sizeof( Point3d );

since, if p3d were set to 0, pv would end up with the value sizeof(Point3d). So, for pointers, the internal conversion requires a conditional test:

// Pseudo C++ Code 
pv = p3d 
   ? (Vertex*)((char*)p3d) + sizeof( Point3d ) 
   : 0;

Conversion of a reference need not defend itself against a possible 0 value, since the reference cannot refer to no object.

А наличие указателей (ссылок) на середину объекта класса плохо для сборки мусора, т.к. сборщик мусора отслеживает указатели (ссылки) на начала выделенных блоков памяти. Можно придумать как эту проблему решить (например, проверять диапазон адресов), но это дополнительное усложнение, а сборщик мусора должен работать быстро.

Это еще без виртуального наследования, которое дополнительно усложняет ситуацию, о чем там дальше идет речь.

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

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

R_>>Наследования, специализация, это вопрос терминологии. И термин наследование, имхо, вполне адекватно и понятно отражает данную сущность.

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

Ну не знаю, вот например такая ситуация:

Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

Теперь я хочу работать с точками в 3д которые также есть графические объекты на экране.
Что здесь более естественно чем двойное наследование?

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

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

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

V>В нединамических языках полиморфизм только через наследование и бывает.
Что за глупость.
Перегрузка операторов и генерики/шаблоны тот же полиморфизм, только времени компиляции.

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

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

B>>Вот ответьте мне опытные, зачем отказались от множественного наследования ? Какова причина ?
B>>Зачем убрали возможность public/protected/private наследования даже в одиночном.
B>>Можно ли все случаи и возможности множ.наследования в проектировании решить с одним одиноночным и n колличеством интерфейсов ?
B>>Может где-то уже тут это обсуждалось... Интересно же знать,что думают учёные по этому поводу

_>Да потому, что Хейлсберг так погрузился в паскакаль, что пропустил мимо ушей такие штуки, как policy, mixins, технику downcasting'а к шаблонным аргументам. Посуществу получилось Delphy II.
Ответил здесь

Автор: Андрей Хропов
Дата: 05.08.06

.

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

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

А конструкторы в природе есть? А делегаторы?

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Так же могут появится и циклические ссылки
Нет, с циклическами это я пожалуй маху дал

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

Мое ИМХО такое: отказались по достаточно простой причине — большинство программистов не умеют правильно пользоваться наследованием. Пренебрегая наследованием интерфейсов (где это можно было сделать), злоупотребляют наследованием реализации (где можно было вообще обойтись без наследования), при этом искажая логику поведения унаследованных классов. А множественное наследование реализаций может увеличть неразбериху на порядок .

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Пусть у меня есть класс 3д точек с операциями сложения, векторного произведения и т.п.
АХ>И есть класс "графический объект на экране", который содержит подпись, умеет ее рисовать и т.п.

АХ>Теперь я хочу работать с точками в 3д которые также есть графические объекты на экране.
АХ>Что здесь более естественно чем двойное наследование?

Уверяю тебя, что ты не хочешь работать "с точками в 3д которые также есть графические объекты на экране". Перефразируя, можно сказать, что точке как графическому объекту на экране не нужны операции сложения, векторного произведения и т.п. Если же получается так, что они нужны, то это означает плохой дизайн и нужно срочно что-то провить в консерватории, а не порождать неестественных классов-уродцев.

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

g_i>А конструкторы в природе есть? А делегаторы?

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

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

Не стоит тогда аппелировать к природе, это слишком общё — думаю и множественному наследованию можно найти аналогию.