Re[7]: оффтопик!
От: Ursus Россия  
Дата: 17.10.02 13:46
Оценка:
Здравствуйте vedmed, Вы писали:

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


EH>>Здравствуйте Igor Trofimov, Вы писали:


A>>>>Меня удивляет, что нигде в современных языках не встречается такая конструкция

A>>>>вроде бы, и код чистый, понятный, хорошая возможность code reuse, присутствует наследование реализации, множественное наследование, как таковое, отсутствует... нет в жизни счастья.

IT>>>Нечто очень близкое есть в Delphi'йском ObjectPascal. Только там надо для каждого метода реализуемого интерфейса указать какой объект и какой его метод подставлять.


EH>>Такое там тоже есть (пометодно). Но есть и следующее:


EH>>создается проперть, возвращающая наследуемый интерфейс и декларируется, что именно она (проперть) и будет этот интерфейс реализовывать. Без шаманских штучек типа вызова компилятора.


V>Подробности на

V>http://nps.vnet.ee/ftp/Docs/Delphi/D5/oplg/objintrf.html#7680

Вопрос не в тему. Откуда такой ник? Я просто такий ник тоже часто пользую ТОлько по русски
Да пребудет с тобой Великий Джа
Re[8]: оффтопик!
От: vedmed  
Дата: 18.10.02 04:35
Оценка:
Здравствуйте Ursus, Вы писали:

U>Вопрос не в тему. Откуда такой ник? Я просто такий ник тоже часто пользую ТОлько по русски


http://rusf.ru/books/xussr_mr/pokrov01.zip

P. S.
Извиняюсь за тему предыдущего ответа, это все слишком умная mozilla
Re[5]: C# ликбез
От: iZEN СССР  
Дата: 18.10.02 07:26
Оценка:
Здравствуйте neutrino, Вы писали:

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


U>> просто попроуй те привести РЕАЛЬНУЮ задачу, в которой действительно небоходимо множественное наследование КЛАССОВ?


N>положим есть класс окна (1) и класс рамки (2), оба имеют готовую реализацию. а мы хотим получить окно в рамке, что мы будем делать?


Изучите паттерн проектирования "Декоратор". Там такой случай как раз описывается (без множественного наследования).
Re[6]: C# ликбез
От: DarkGray Россия http://blog.metatech.ru/post/ogni-razrabotki.aspx
Дата: 18.10.02 12:32
Оценка:
ZEN>Изучите паттерн проектирования "Декоратор". Там такой случай как раз описывается (без множественного наследования).

Проблема в том, что патерн "Декоратор" быстро и эффективно можно реализовать на существующих языках только через наследование. Например, надо нам задекорировать один метод, если мы это делаем не через наследование, то придется для всех остальных методов написать руками тонну wrapper-ов (C#, конечно, это проще, т.к. можно делать не руками)
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.