39-wayerr >

[I]в итоге у вас "интерфейс" списка будет содержать 25 методов
[/I]

А как иначе программе объяснить, что она должна делать при попытке передать списку мышей параметра-слона на вход? Только кодированием метода. Революционный (для своего времени) вин ООП - что это можно сделать ОДИН раз, на уровне методов. А не тягать по всему коду системы блоки из 25 кусков if-then-else.

[I]причем не дельфи, а имитиацию синтаксиса objectpascal на платформе .net, для тех кто не осилил C#
[/I]
Это был как раз чистый Delphi, пятерочка, под Win32. Безо всяких противных .NET и С#. Более того, я использовал этот код для генерации отчетов FreeReport, отображая функции объекта напрямую в отчет, без дополнительных строчек-переходников.

>А как иначе программе объяснить, что она должна делать при попытке передать списку мышей параметра-слона на вход?

в моем коде это и объясняется программе

>это можно сделать ОДИН раз, на уровне методов

на самом деле это kill, потому что методы будут дублироваться в большой системе, а на реальных задачах все скатится к множественному наследованию и макаронам методов, потому многие против вашего подхода ([url]http://www.codeart.ru/2010/08/03/nasledovanie-protiv-kompozicii-chto-predpochtitelnee/[/url] для примера, гдето были статьи "мужиков" на сию тему но щас ночь)

42-wayerr >
[I]а на реальных задачах все скатится к множественному наследованию[/I]

За 12 лет ни разу не пришлось использовать множественное наследование, даже в виде костылей-интерфейсов. В одном моем проекте - 250 классов. ЧЯДНТ?

42-wayerr > Статью прочитал. Фаулер пишет про это лучше :-)

>В одном моем проекте - 250 классов. ЧЯДНТ?

наверное не пишешь проекты где больше тысячи классов, не?

Прочитал статью. Имхо всё это - следствия отсутствия проекта. В идеале если ТЗ перевести сначала в объектную модель, а потом уже приступать к реализации, то на грабли скорее всего и не наступишь.
А если сразу взяться за карандаш....
void main()
**
Пишу что всё пропало :-))) ;
**

45-wayerr >
[I]наверное не пишешь проекты где больше тысячи классов, не?
[/I]

Пока не приходилось. Но все равно, смысл множественного наследования мне непонятен.

Вот из моей практики. Много работал с риэлторами. Базы всякие, скрипты для упрощения будней.

Разгребал поделку своего коллеги. У него был класс "Дом" и класс "Участок". Когда ему понадобилось сделать объект "Загородный дом", он, недолго думая, сделал его как потомка этих двух классов. Решение? Возможно.

Я же переделал эту схему с использованием паттерна "Фасад", слегка упрощенного и искаженного. Объект "Недвига" содержит ссылки на все возможные объекты в нем. Например, на дом, землю и сарай. А там уже можно изгаляться - скажем, применить "Null-объект" при отсутствии сарая, или считать цену как сумму отдельных вложенных классов.

В целом, дискуссию считаю скорее бесполезной. Мне нравится ООП, потому что позволяет изящно решать те задачи, который ВСТАВАЛИ передо мной. Когда упрусь рогом во что-то непригодное для ООП - мое мнение, возможно, поменяется.

>Мне нравится ООП

а я не говорил что ооп - говно, я лишь к тому что это не панацея 8)

читатель # 1: представим себе сферу.
читатель # 2: идеально сферических объектов не существует.
читатель # 1: я же сказал: представим.
читатель # 2: это я просто что бы вы помнили.

49-vxg > бгг :)