Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Потрепаться";
Текущий архив: 2004.08.29;
Скачать: [xml.tar.bz2];

Вниз

Вот спорю с коллегой на работе, подскажите есть ли множественное   Найти похожие ветки 

 
Rule ©   (2004-08-10 09:44) [0]

наследие классов в делфийском обджект паскале, если нет то как обходится эта проблемма, а если да то как реализовать это чудо ?


 
Думкин ©   (2004-08-10 09:58) [1]

А что спорить? Нету. А зачем?


 
Ega23 ©   (2004-08-10 10:00) [2]

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


 
Skyle ©   (2004-08-10 10:01) [3]

Удалено модератором
Примечание: Личная переписка


 
VMcL ©   (2004-08-10 10:03) [4]

>>Rule ©  (10.08.04 09:44)

Для классов, реализующих интерфейсы, есть: можно в одном классе реализовать несколько интерфейсов. Для обычных классов - нет.

P. S. Ну и как правильно отметил [1]: а зачем? :)


 
Юрий Зотов ©   (2004-08-10 10:03) [5]

1. Сабж - нет.
2. Как обходится - по-разному, от задачи зависит.
3. Как реализовать - написать свой компилятор.


 
Anatoly Podgoretsky ©   (2004-08-10 10:03) [6]

В большинстве языков этого нет, вот и в СиДиез убрали.


 
Игорь Шевченко ©   (2004-08-10 10:06) [7]

Думкин ©   (10.08.04 09:58) [1]


> А зачем?


Затем же, зачем в С++, не так ли ?


 
Думкин ©   (2004-08-10 10:06) [8]

Удалено модератором
Примечание: Личная переписка


 
Думкин ©   (2004-08-10 10:07) [9]

> [7] Игорь Шевченко ©   (10.08.04 10:06)

Я не спорю, а спрашиваю. Мне вот напрямую пока никак. Обходился, хотя были иногда желания. :)


 
Игорь Шевченко ©   (2004-08-10 10:09) [10]

Думкин ©   (10.08.04 10:07) [9]

Мне, например, из-за его отсутствия приходится писать лишний код. Иногда напрягает.


 
Думкин ©   (2004-08-10 10:10) [11]

> [10] Игорь Шевченко ©   (10.08.04 10:09)

Да, для обхода приходится попотеть. Видимо, есть зачем. :)
Я потел.


 
han_malign ©   (2004-08-10 10:12) [12]

Множественное наследование - это всего лишь агрегация, а делать ее явно - средствами любого объектного языка, или неявно - магией С++, личное дело каждого...


 
Гаврила ©   (2004-08-10 10:13) [13]


> Игорь Шевченко ©   (10.08.04 10:09) [10]


а зачем лишний код ?
через implements вроде как лишенго кода писать и не надо


 
Anatoly Podgoretsky ©   (2004-08-10 10:14) [14]

han_malign ©   (10.08.04 10:12) [12]
Аггрегация и наследования разные вещи, аггрегация поддержана полностью.


 
Игорь Шевченко ©   (2004-08-10 10:20) [15]


> через implements вроде как лишенго кода писать и не надо


? это как, не соображу с утра :)


 
Rule ©   (2004-08-10 10:23) [16]

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


 
Думкин ©   (2004-08-10 10:25) [17]

>  [16] Rule ©   (10.08.04 10:23)

А также по шаблонам, двухпроходности и т.д. и т.п?


 
REA ©   (2004-08-10 10:26) [18]

В ООН лучше написать. И лично Нельсону Манделе.


 
Rule ©   (2004-08-10 10:29) [19]

REA ©   (10.08.04 10:26) [18]

Да зачем, последователям Бен-Ладена написать типа так и так америкосы опять обижают нормальных людей, правоверных мусульман, нарушают принципы корана в программировании, что делать?

и я думаю пробемма решится :)


 
Romkin ©   (2004-08-10 10:31) [20]

Игорь Шевченко ©  (10.08.04 10:20) [15] implements - это для интерфейсов :))
Rule ©  (10.08.04 10:23) [16] Нет. И не надо :)


 
Игорь Шевченко ©   (2004-08-10 10:37) [21]

Romkin ©   (10.08.04 10:31) [20]


> implements - это для интерфейсов :))


На таком уровне я знаю :)
Но не соображу, как можно указанием implements избавиться от написания кода для создания подобия множественного наследования. Где будет реализация методов интерфейса ?


 
Skyle ©   (2004-08-10 10:47) [22]


> Anatoly Podgoretsky ©   (10.08.04 10:14) [14]
> Аггрегация и наследования разные вещи, аггрегация поддержана
> полностью.


А что значит "аггрегация"?
Это что-то типа этого?

TSomeClass = class(...)
 FSomeField : TSomeAnotherClass;

То есть, объектные поля в классах?

P.S. Подозреваю, что терминология страдает, так что если я неправ, скажите хоть, как это правильно называется...;-)


 
Иван Шихалев ©   (2004-08-10 10:54) [23]


> Но не соображу, как можно указанием implements избавиться
> от написания кода для создания подобия множественного наследования.
> Где будет реализация методов интерфейса ?




type
 I1 = interface
    ......
   end;

 I2 = interface
    ......
   end;

 C1 = class(TInterfacedObject,I1)
    ... реализуем I1 ...
   end;

 C2 = class(TInterfacedObject,I2)
    ... реализуем I2 ...
   end;

 CM = class(C1,I2)
    .....
    property P2 : C2 implements I2
    .....
   end;
</cide>

CM унаследовал реализацию I1 от C1 и делегировал реализацию I2 к C2. Сам он уже не должен что-либо реализовывать. Правда в конструкторе, наверное, придется создавать экземпляр C2 в какое-то свое поле...


 
Иван Шихалев ©   (2004-08-10 10:55) [24]

Назвается - реализация делегированием :)


 
Гаврила ©   (2004-08-10 10:57) [25]


> Игорь Шевченко ©   (10.08.04 10:37) [21]


class1 реализует interface1
class2 реализует interface1 и  interface2

экземпляр class1 является полем  class2
class2 реализует interface2 сам, а interface1 перенаправлением вызовов на class1 с помощью implements,  то есть без кода реализации


 
Гаврила ©   (2004-08-10 11:00) [26]

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


 
DiamondShark ©   (2004-08-10 11:07) [27]


> Игорь Шевченко ©   (10.08.04 10:37) [21]
> Но не соображу, как можно указанием implements избавиться
> от написания кода для создания подобия множественного наследования.

А что, множественное наследование уже избавляет от написания кода?


> Где будет реализация методов интерфейса ?

В агрегируемом объекте.

Вообще-то, реализация интерфейсов -- более прозрачная и логичная схема, чем множественное наследование.

Кстати, можно пример задачи, где без множественного наследования плохо живётся?


 
Romkin ©   (2004-08-10 11:25) [28]

Да, интерфейсы - второй этап ООП, устраняются многие неясности.
А без множественного наследования нормально живется :))
Кстати, в D6 TComponent уже реализует интерфейс. Только недавно узнал :(


 
Гаврила ©   (2004-08-10 11:30) [29]


> Кстати, можно пример задачи, где без множественного наследования
> плохо живётся?


Некоторые компоненты (потомки TControl) также имеют машинку UNDO. Для "двух стрелочек" в панели кнопок. По обработке метода Undo так же существует иерархия классов


 
Игорь Шевченко ©   (2004-08-10 11:35) [30]

Romkin ©   (10.08.04 11:25) [28]


> Кстати, в D6 TComponent уже реализует интерфейс. Только
> недавно узнал :(


В D5 тоже.

DiamondShark ©   (10.08.04 11:07) [27]


> А что, множественное наследование уже избавляет от написания
> кода?


Я не писал - избавляет.


> Вообще-то, реализация интерфейсов -- более прозрачная и
> логичная схема, чем множественное наследование.


Множественное наследование не менее прозрачно и логично.


> Кстати, можно пример задачи, где без множественного наследования
> плохо живётся?


Скажем, иерархия классов, умеющая сохраняться и восстанавливаться из потока. (Для примера - реализация Turbo Vision в Borland C++)


 
DiamondShark ©   (2004-08-10 11:48) [31]


> Скажем, иерархия классов, умеющая сохраняться и восстанавливаться
> из потока. (Для примера - реализация Turbo Vision в Borland
> C++)


Мимо! Это как раз и была эмуляция интерфейсов.
Собственно, все примеры с МН, которые я видел, представляют собой именно такую эмуляцию.

Так что фтопку.


 
Romkin ©   (2004-08-10 12:01) [32]

Игорь Шевченко ©  (10.08.04 11:35) [30] в D5 это не так явно :))
Впрочем, наворотили то еще...
И вообще, множественное наследование классов устарело :)


 
Rule ©   (2004-08-10 12:06) [33]

Romkin ©   (10.08.04 12:01) [32]

И вообще, множественное наследование классов устарело :)

Ха, вот этим и буду аргументировать свои доводы по поводу того что оно не надо и можно без этого обойтись


 
Игорь Шевченко ©   (2004-08-10 12:07) [34]

Romkin ©   (10.08.04 12:01) [32]


> И вообще, множественное наследование классов устарело :)


Мода прошла ? :)

Я не совсем понимаю термина "устарел" применительно к наследованию.


 
Гаврила ©   (2004-08-10 12:15) [35]

В принципе, может быть и устарело...
Как в свое время устарело линейное программирование, когда на смену пришло ООП


 
имя   (2004-08-10 12:19) [36]

Удалено модератором


 
Игорь Шевченко ©   (2004-08-10 12:21) [37]

Гаврила ©   (10.08.04 10:57) [25]


> class1 реализует interface1
> class2 реализует interface1 и  interface2
>
> экземпляр class1 является полем  class2
> class2 реализует interface2 сам, а interface1 перенаправлением
> вызовов на class1 с помощью implements,  то есть без кода
> реализации


Но при этом придется создавать экземпляр class1, передавать ему ссылку на экземпляр class2 (чтобы методы, реализованные в class1 знали о данных class2), правильно ?


 
Romkin ©   (2004-08-10 12:24) [38]

Игорь Шевченко ©  (10.08.04 12:07) [34] Применительно к множественному наследованию классов ;)
Просто наследование никто не отменяет. А устарело потому, что на смену ему пришло наследование интерфейсов.
Простой пример: у предка есть виртуальный метод, наследник его перекрывает, но не вызывает в нем inherited, собственно метод предка. Допустимо ли это технологией? Конечно. Но ведь потомок не знает, что делает метод предка, который он не вызвал. А он может делать что-то, затрагивающее функциональность предка, да хоть количество его вызовов подсчитывать :) Вот и получается, что программист, написав потомок, вторгся в логику работы предка, и изменил ее!
Понятно, есть соглашения, что надо, что не надо... Но это - соглашения. И как правило, приходится смотреть код предка, когда пишешь потомка.
А при использовании интерфейсов таких тонкостей просто нет. И более того, с интерфейсами для того, чтобы твой класс воспринимался как предок, ты не обязан порождать свой класс от предка, можно просто реализовать его интерфейс. Так, как хочется.
А если еще учесть, что при использовании интерфейсов есть возможность агрегировать в себя (читай - унаследовать) всю функциональность класса, написанного на другом языке, то становиться понятным, почему я говорю, что множественное наследование классов устарело :))


 
Romkin ©   (2004-08-10 12:30) [39]

Игорь Шевченко ©  (10.08.04 12:21) [37] Немного не так. Создавать придется. Но перенаправлять ничего не надо, все, что нужно агрегату, это IUnknown class2. А это предусмотрено, см CoCreateInstance, параметр pUnkOuter :))
То есть, агрегирование - это несколько строк кода, объявить и создать, сообщив ему, что он - агрегирован. Указывать надо по той причине, что при агрегации будет использоваться счетчик ссылок контейнера, а не агрегируемого объекта. Остальное - полностью без изменений.


 
Гаврила ©   (2004-08-10 12:31) [40]


> Игорь Шевченко ©   (10.08.04 12:21) [37]


Создать class1 надо конечно, поскольку он является полем class2, то и создать его логично в конструкторе class2. Вот и весь код. НУ а передавать ли ему ссылку на class1 - от задачи зависит :-)


 
Игорь Шевченко ©   (2004-08-10 12:33) [41]

Romkin ©   (10.08.04 12:24) [38]


> А если еще учесть, что при использовании интерфейсов есть
> возможность агрегировать в себя (читай - унаследовать) всю
> функциональность класса, написанного на другом языке, то
> становиться понятным, почему я говорю, что множественное
> наследование классов устарело :))


Множественность-то здесь причем ? Вся эта фраза точно также относится и к одиночному наследованию.


> А при использовании интерфейсов таких тонкостей просто нет.
> И более того, с интерфейсами для того, чтобы твой класс
> воспринимался как предок, ты не обязан порождать свой класс
> от предка, можно просто реализовать его интерфейс. Так,
> как хочется.


Дублируя код предка, если требуется его функциональность ? :))


> Простой пример: у предка есть виртуальный метод, наследник
> его перекрывает, но не вызывает в нем inherited, собственно
> метод предка. Допустимо ли это технологией? Конечно. Но
> ведь потомок не знает, что делает метод предка, который
> он не вызвал. А он может делать что-то, затрагивающее функциональность
> предка, да хоть количество его вызовов подсчитывать :) Вот
> и получается, что программист, написав потомок, вторгся
> в логику работы предка, и изменил ее!


Опять же, причем тут именно множественное наследование ? Все это точно так же может быть отнесено к одиночному наследованию, однако его, почему-то ничкто не отменяет и не пишет, что оно устарело :))


 
Игорь Шевченко ©   (2004-08-10 12:34) [42]

Romkin ©   (10.08.04 12:30) [39]


> Создавать придется. Но перенаправлять ничего не надо, все,
> что нужно агрегату, это IUnknown class2. А это предусмотрено,
> см CoCreateInstance, параметр pUnkOuter


Я вообще-то не про COM...Я вообще-то про обычное использование интерфейсов и наследование...Я в COM не так силен, как ты :)


 
DiamondShark ©   (2004-08-10 12:35) [43]

Дело в том, что наследование и реализация интерфейсов -- разные по назначению вещи.
Наследование -- инструмент повторного использования кода.
Интерфейсы -- инструмент структурирования предметной области, задачи, модели.


 
Игорь Шевченко ©   (2004-08-10 12:36) [44]

Гаврила ©   (10.08.04 12:31) [40]


> Создать class1 надо конечно, поскольку он является полем
> class2, то и создать его логично в конструкторе class2.
> Вот и весь код. НУ а передавать ли ему ссылку на class1
> - от задачи зависит :-)


Только вот я не совсем понимаю, чем это лучше, чем множественное наследование ? :)


 
Гаврила ©   (2004-08-10 12:39) [45]


> Игорь Шевченко ©   (10.08.04 12:36) [44]


Да это и не лучше, просто нет его, множественного наследования у нас :-)


 
Romkin ©   (2004-08-10 12:40) [46]

Игорь Шевченко ©  (10.08.04 12:33) [41] При том, что оно становиться не нужным :)))
А одиночное - можно обойтись и без него, но оно удобно. А главное - достаточно.
>Дублируя код предка, если требуется его функциональность ? :))
Вот именно. Ты можешь унаследовать предка, можешь его агрегировать, а можешь продублировать его фукнциональность :)
На выбор. И при этом пользователь твоего потомка просто не догадается, как именно ты сделал :)))
Более того, пользователь часто вообще не знает, как и где именно реализован данный интерфейс ;)


 
Игорь Шевченко ©   (2004-08-10 13:08) [47]

DiamondShark ©   (10.08.04 12:35) [43]


> Наследование -- инструмент повторного использования кода.


Игорь Шевченко ©   (10.08.04 10:09) [10]


> Мне, например, из-за его отсутствия приходится писать лишний  > код. Иногда напрягает


:)

Romkin ©   (10.08.04 12:40) [46]

> А одиночное - можно обойтись и без него, но оно удобно.
> А главное - достаточно.


Честно говоря, не понимаю :)


> Вот именно. Ты можешь унаследовать предка, можешь его агрегировать,
> а можешь продублировать его фукнциональность :)


Собственно говоря, введение множественного наследования не мешает мне сделать те же три действия :)


> Более того, пользователь часто вообще не знает, как и где
> именно реализован данный интерфейс


Какой пользователь имеется в виду ?


 
Антон   (2004-08-10 13:16) [48]

Я вообще-то в Delphi не секу, пишу на С++, а этот форум зинтересовал меня по простой причине, хочу понять, есть ли объективые причины почему в Delphi не реализовано множественное наследование. Я исключаю ответы типа устарело, излишне, приводит к ошибкам. Основной вопрос - может ли это быть связано с различием в процессах распеделения памяти и т.п.

А вообще множественное наследование легко реализуется простым вложением двух объектов различных классов в качестве членов третьего, далее остается только предоставить код, возвращающий адреса этих объетов. Так например:


class A { };
class B { };

class C : public A, public B { };
экивалентно
class C { A a; B b; }



 
Игорь Шевченко ©   (2004-08-10 13:22) [49]


> А вообще множественное наследование легко реализуется простым
> вложением двух объектов различных классов в качестве членов
> третьего, далее остается только предоставить код, возвращающий
> адреса этих объетов. Так например:
>
>
> class A { };
> class B { };
>
> class C : public A, public B { };
> экивалентно
> class C { A a; B b; }


Не эквивалентно. Класс C не может быть представлен ни как класс A, ни как класс B


 
Антон   (2004-08-10 13:29) [50]

Хорошо, продолжу:

struct A {};
struct B {};
struct C {
  A a; B b;
  operator A* () { return &a; }
  operator B* () { return &b; }
};

void f()
{
  C c;
  A* p_a = c;
  B* p_b = c;
  cout << p_a << " " << p_b << " " << &c << endl;
}

В результате видим примерно следующее:
0012FF74 0012FF78 0012FF74
Это аблолютная аналогия.


 
Игорь Шевченко ©   (2004-08-10 13:46) [51]


> В результате видим примерно следующее:
> 0012FF74 0012FF78 0012FF74
> Это аблолютная аналогия.


???????????????????? Эт как ?


 
Piter ©   (2004-08-10 13:57) [52]

Игорь Шевченко ©   (10.08.04 10:09) [10]
Мне, например, из-за его отсутствия приходится писать лишний код. Иногда напрягает


а можно пример, когда множественное наследование полезно?


 
Антон   (2004-08-10 13:58) [53]

> ???????????????????? Эт как ?
Аналогичный результат я получу если просто напишу класс С при помощи синтаксиса множественного наследования, как показывал выше. Дело в том, что память распределится идентичным образом в обоих случаяю, поэтому разницы никакой нет.


 
Антон   (2004-08-10 14:02) [54]

> а можно пример, когда множественное наследование полезно?

Есть такой мультик - КОТОПЕС, а если серъезно, то любое моделирование гибридных объектов.


 
Piter ©   (2004-08-10 14:46) [55]

Антон   (10.08.04 14:02) [54]

нет, мне бы пример. Например, постановка задачи и путь ее реализации. Желательно в терминах Delphi

Например, нечто реализовывается так. Но вот если было бы множественное наследование - то это можно было бы реализовать гораздо проще, потому что...


 
DiamondShark ©   (2004-08-10 14:51) [56]


> то любое моделирование гибридных объектов.

Агрегирование.


 
Игорь Шевченко ©   (2004-08-10 14:59) [57]


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


Это зависит от конкретной реализации языка, не так ли ?
Синтаксис наследования является стандартом языка, в то время, как распределение памяти стандартом отнюдь не является.


 
Антон   (2004-08-10 15:43) [58]


> Это зависит от конкретной реализации языка, не так ли ?
> Синтаксис наследования является стандартом языка, в то время,
> как распределение памяти стандартом отнюдь не является.

Вот это меня и интерисует, я как абсолютный профан в Delphi, не знаю можно ли аналогично реализовать множественное наследование посредством агрегации, как я показал на примере с С++. Это был пример для обсуждения и не больше. Что мешает реализовать аналогично множественное наследование в Delphi, вот в чем вопрос? Ведь у вас есть простое наследование, нет операторов преобразования типа как в С++, но их можно заменить и на обычные ф-ии члены класса (воспрос синтаксиса)?


 
Антон   (2004-08-10 15:50) [59]


> нет, мне бы пример. Например, постановка задачи и путь ее
> реализации. Желательно в терминах Delphi
>
> Например, нечто реализовывается так. Но вот если было бы
> множественное наследование - то это можно было бы реализовать
> гораздо проще, потому что...

Прости, в терминах Delphi не могу, просто не знаю, да и дело не в терминах. Я могу привести пример реализации библиотеки Motif. Она не относится к вопросу о множественном наследовании. Но она эмулирует C++ в части скрытия данных и разграничения доступа, хотя это чисто С библиотека. Можно использовать средства языка для эмуляции средств не реализованных в языке, но проще пользоваться синтаксисом заложенным изначально в язык, по моему это удобнее.


 
Игорь Шевченко ©   (2004-08-10 15:51) [60]


> Вот это меня и интерисует, я как абсолютный профан в Delphi,
> не знаю можно ли аналогично реализовать множественное наследование
> посредством агрегации, как я показал на примере с С++.


Я имел в виду, что в различных реализациях одного языка (С++) реализация может быть разная.


 
Антон   (2004-08-10 16:09) [61]


> Я имел в виду, что в различных реализациях одного языка
> (С++) реализация может быть разная.

Понял твой намек. Дело в том что модесь COM, которая упоминалась в форуме реализуется именно с помощью агрегации, спорить с этим бесполезно. Так на чем же она основывается? Ответ очевиден. Что-бы предоставить доступ к интерфейсу, не использую конструкции C++, приходится эмулировать его с помощью агрегации...


 
Mystic ©   (2004-08-10 16:18) [62]

Вот пример. Есть библиотека где представлены различные классы (со своей иерархией наследования), в том чсле TSomeClass. Допустим, эту библиотеку мы изменять не можем. В определенный момент равития системы (пишется компонет, имеюший published свойство типа TSomeClass). Нам надо чтобы этот класс был порожден от TPersistent и умел сохраняться в поток, присваиваться и т. д.


 
Антон   (2004-08-10 16:28) [63]


> Я имел в виду, что в различных реализациях одного языка
> (С++) реализация может быть разная.

Я думаю, ты понял, что проблема не в реализации компилятора, а в том, что компилятор для Object Pascal невозможно реализовать аналогично, что именно мешает мне и интересно, возможны варианты, один из которых - однопроходность, но это только для затравки...


 
Игорь Шевченко ©   (2004-08-10 16:30) [64]


> Я думаю, ты понял, что проблема не в реализации компилятора,
> а в том, что компилятор для Object Pascal невозможно реализовать
> аналогично, что именно мешает мне и интересно, возможны
> варианты, один из которых - однопроходность


Однопроходность здесь ни с какого боку, вроде...

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


 
Cobalt ©   (2004-08-10 16:49) [65]

2 Mystic ©   (10.08.04 16:18) [62]
Минуточку - тут имеет место небольшое лукавство:
Если это компонент (для формы/ДатаМодуля) - он уже наследуется от TPersistent - и это упрощает дело
Если же это просто класс - то это уже не проблема вызвать у него метод SaveToStream самому (на мой взгляд).


 
Игорь Шевченко ©   (2004-08-10 17:02) [66]


> Если же это просто класс - то это уже не проблема вызвать
> у него метод SaveToStream самому (на мой взгляд).


А если его нету ?


 
Антон   (2004-08-10 17:17) [67]


> > Если же это просто класс - то это уже не проблема вызвать
> > у него метод SaveToStream самому (на мой взгляд).
> А если его нету ?

Причем метод которого нету, можно конечно реализовывать "ЖИРНЫЙ" интерфейс, который предусматривает чисто фиртуальные метомы (в вашем понимании интерфейсы), обеспечивая совместимость на уровне вызова ф-ий членов, но для чего? Елсли нет возможности преобразовать тип во время исполнения в производный, только тогда возможен изврат с ЖИНЫМ интерфейсом (а как на счет производных классов которые в приципе не могут реализовать данный интерфейс..., что делать заглушки...?)


 
Cobalt ©   (2004-08-10 17:52) [68]

Хм..
Есть класс (TParent1), который изменять нельзя. Порождён не от TMyClass1.
Надо: Добавить ему функционал этого TParent2.

 Решение 1: Без использования множественного наследования
Добавляем в новый класс(TChild) поле типа TParent2. Устанавливаем его свойства, обработчики и т.п. Везде, где надо, суём поле, а не сам класс (TChild).
+ Хорошо, если этот функционал не должен затрагивать функционал и поля TParent1.
- Плохо, если необходимо чтобы новый функционал работал с полями исходного класса TParent1 как со своими собственными

 Решение 2: С использованием множественного наследования
Добавляем в новый класс(TChild) родителя типа TParent2. У него появляются новые поля и методы для исполнения соответствующего функционала.

Вопрос - как TParent2 должен взаимодействовать с Методами и Полями другого TParent1 в TChild?


 
Cobalt ©   (2004-08-10 17:53) [69]

Я как-то пока себе не представляю.


 
Cobalt ©   (2004-08-10 18:08) [70]

Ещё - если функционал TParent2 должен работать с полями TParent1, то в TChild надо переписывать эти методы.

Выигрыш - TChild на вопрос is TParent1 ответит True, и позволит работать с классом, как с TParent1.

P.S.
Cobalt ©   (10.08.04 17:52) [68]
Следует читать:
Есть класс (TParent1), который изменять нельзя. Порождён не от TParent2.
Надо: Добавить ему функционал этого TParent2.


 
Romkin ©   (2004-08-10 18:13) [71]

Бррр. Ну что вы маетесь?! Я вообще уже ничего не понимаю.
В Delphi нет множественного наследования классов. Оно не обязательно.
Но если очень хочется - есть множественное наследование интерфейсов, и пользоваться им гораздо приятнее :)
Например, можно создать потомка на Delphi от класса, написанного на С++ Ж-)


 
Cobalt ©   (2004-08-10 18:26) [72]

просто меня тоже заинтересовало - были ли какие-то объективные причины для того, что бы не реализовывать множественное наследование в Delphi? Или просто решили, мол, нафиг это не надо, не будем с этим заморачиваться, и вообще это непопулярно, и забили на этом жирный крест.


 
Romkin ©   (2004-08-10 18:35) [73]

Естественно, просто решили.
Надо будет - введут. Но лучше не надо :)


 
Cobalt ©   (2004-08-10 19:49) [74]

Отчего же?
Довольно-таки удобно, компилятор будет ругаться на вызов метода без указания его родителя (при наличии нескольких одноимённых у разных предков), все будут довольны :)


 
Бином Ньютоныч   (2004-08-10 19:54) [75]

Причины, имхо, вполне конкретые. Множ. наследование - бред бушевноболдьного. Два - три этапа - и в эторм классе сам черт со страуртруппом не разберутся, не говоря уж про нас, бедных...:(


 
Бином Ньютоныч   (2004-08-10 19:57) [76]

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


 
Cobalt ©   (2004-08-10 20:56) [77]

2 Бином Ньютоныч   (10.08.04 19:54) [75]
Ну, не скажите. Если программист запутался втом, что же делает  (может делать) его класс - это его проблема. при строгом непересекающемся наследовании я не вижу проблем составить карту методов и полей, унаследованных от всех его родителей.

Единственная проблема, которую я углядел - конфликт Published-свойств у компонентов - как их отображать? сохранить в dfm?
Загружать из dfm? Вот это, кажется - самое трудное - пришлось бы, наверное, добавлять в RTTI данные о классах и их Published-свойствах - для того, что бы можно было выбирать. Типа
GetParentClass(Parent1Name).SetProperty(PropertyName1).AsString

P.S. Я пробовал смотреть исходники TReader, но, честно говоря, не понял - где же он устанавливает значение Published-свойств?


 
Бином Ньютоныч   (2004-08-10 21:32) [78]

>Cobalt ©   (10.08.04 20:56) [77]

Извините, но большая часть Вашей работы - это использование чуого кода(VCL) И это здорово, я не против:)

Да нет, Вы просто попробуйте построить иерархию со множественным наследованием. Ничего сложного не используйте, все обыденно: источник данных, обраьотчик коллизий, интерфейс юзера... Потом сделайте еще шаг - администратор. Потом Вам(юзеру) захочется быть супервизором. А кому не хочется - всем хочется. Но мы не позволим, мы умные, видали уже. Однако заказчик настаивает. Ладно, Вы обговорили бабки, но слабина уже есть! Он захочет большего, причем в рамках. Откажешь? Дудки, это же клиент, деньги, жизнь... А дальше? Ну сколько ты будещь расширять функ. в рамках языка? А когда выйдет за рамки?  Но это все хрень. Что мне ДЕЙСТВИТЕЛЬНО непонятно - как ты будешь обеспечивать БЕЗОПАСНОСТЬ всей этой хрени? Поделись:)


 
Cobalt ©   (2004-08-10 21:47) [79]

Я чувствую, ты что-то хочешь сказать мне, что-то наболевшее...
Но вот что - я никак не пойму.


 
Cobalt ©   (2004-08-11 17:37) [80]

Может, ещё какие есть объективные причины для отсутствия множественного наследования?



Страницы: 1 2 вся ветка

Форум: "Потрепаться";
Текущий архив: 2004.08.29;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.69 MB
Время: 0.046 c
14-1092013180
Sergey Kaminski
2004-08-09 04:59
2004.08.29
Дурацкие законы


14-1092059884
Igorek
2004-08-09 17:58
2004.08.29
Супер идея - двоядерный компьютер!!! Критикуйте!


3-1091522796
MORA
2004-08-03 12:46
2004.08.29
Подстановочные поля


1-1092202179
FastByte
2004-08-11 09:29
2004.08.29
вставка слов в объект класса TRichEdit


14-1091886853
able
2004-08-07 17:54
2004.08.29
НАШЕствие





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский