Перейти из форума на сайт.

Новости • Файловые архивы
Поиск • Активные темы • Топ лист
Правила • Кто в on-line?
Вход • Забыли пароль? • Первый раз на этом сайте? • Регистрация
Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE4

Модерирует : ShIvADeSt

 Версия для печати • Подписаться • Добавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Открыть новую тему     Написать ответ в эту тему

deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Eternal_Shield

Цитата:
Нету в этих языках понятия интерфейс, имхо.

 
Хм. Тогда переспрошу - а чем принципиально отличаются интерфейсы C#/Java от Delphi?
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 13:44 18-06-2013
Eternal_Shield

Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ego666

Цитата:
это вообще из другой оперы.  

Не IDispatch ли решает подобную проблему .. по типу той, что в примере? ...
 

Цитата:
COM рекомендует писать интерфейсы с неопределённым смыслом (с простым/обобщённым/универсальным наименованием методов), чтобы каждая отдельная реализация этого интерфейса могла его, "смысл" интерфейса, интерпретировать по своему.

Верно, 1 интерфейс - N реализаций ... и как сие попадает под определение, что родитель должен знать о всех методах всех своих наследников? В постулатах COM о таких отношениях/обязанностях ни слова.
 
В нашем случае, как IList может знать о методах в своих наследниках IFileFile, IStreamList и т.п.? С какого перепугу vtbl родителя изменится, чтобы отразить методы его наследников? ...  
 
deks

Цитата:
Хм. Тогда переспрошу - а чем принципиально отличаются интерфейсы C#/Java от Delphi?

Тем, как происходит наследование. Сие различие портит восхитительный интероп между C# приложением и Delphi DLL в нашем чудном проекте
 
Это относится к C#, а не Java.
Всего записей: 767 | Зарегистр. 18-05-2009 | Отправлено: 15:07 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Eternal_Shield
 

Цитата:
Тем, как происходит наследование

 
Пока мне кажется, что в Дельфи использование наследования интерфейсов происходит через Ж. Абсолютно не вижу логики.  
 
Пример старый:
Код:
 
IParent=interface
    procedure P1;
  end;  
 
  IChild=interface(IParent)  
    procedure P2;
  end;  
 
  TChild=class(IChild)
    procedure P1;
    procedure P2;
  end;  
 
var  
  i_parent: IParent;  
  i_child: IChild;  
  chld: TChild;  
begin  
  chld := new TChild;
   
  i_child := chld;     // (1) OK  
  i_parent := chld;   // (2)
  i_parent := i_child; // (3)  
 
  i_parent.P1;
   
  i_child.P1;
  i_child.P2;  
end;

 
проверил пример в Оксигене.NET - все работает так, как ожидается, ошибок нету, нужные интерфейсы достаются как надо.  
 
В СмартМобайлСтудио (DWS) будет ошибка на строке (2) если не указать при декларации TChild оба интерфейса - и IParent, и IChild. Причем если у TChild оставить только P2, а не указать P1 из IParent, то компилятор ошибку ловит (не хватает реализации IPArent.P1). То есть на стадии компиляции он, сцуко, про все поддерживаемые в TChild интерфейсы знает, но при присваивании "узнавать" IParent не хочет! ) Нелогично!) Зачем такое поведение в SmartMS которое вообще COM с рождения не видело - хз. Впрочем, это Дельфи-стайл.
 
В Лазаре с FPC2.6.2 аналогично DWS - или нужно явно указать родительский интерфейс, или мы не сможем достать родительский интерфейс из объекта!  
 
WTF! - нелогично же. Зачем так сделано? Понимаю все проблемы COM, но это ж прошлый век! Даже голимый C# от этого ушел!
 
ego666
 
По поводу примера с IList и IFileList. А с какого перепуга мы достаем из объекта интерфейс IList и пытаемся работать с ним как с IFileList? Когда же предок позволял работать с собой как с потомком? Это наоборот можно - достав IFileList потом кастануть его к родителю IList. Но не наоборот! И да, я в упор не понимаю в чем логика, что достать из объекта можно только ЯВНО в декларации указанный интерфейс, а родительский интерфейс компилятор видит, требует поддерживать, но "доставать" его из объектов отказывается.  
 
 
Добавлено:
upd
 
Написал про такое поведение DWS Эрику (в issue tracker)- пусть думает, нафига козе баян. Интересно - что ответят!
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 15:38 18-06-2013
AlekXL



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
WTF! - нелогично же.  

ну вообще, Diamond проблема и впрямь может нарисоваться(в Win32):

Код:
 
program Project24;
 
{$APPTYPE CONSOLE}
 
{$R *.res}
 
uses
  System.SysUtils;
  type
  IChild=interface
  function PreferDolls():boolean;
  end;
 
  IBoy=interface(IChild)
 
  end;
 
  IGirl=interface(IChild)
 
  end;
 
  TBoy=class(TInterfacedObject,IBoy)
     function PreferDolls():boolean;
  end;
 
 
  THermAphrodite=class(TInterfacedObject,IBoy,IGirl)
  strict protected
  FBoy:IBoy;
  property Boy:IBoy read FBoy implements IBoy;
  procedure AfterConstruction();override;
  public
  function PreferDolls_g():boolean;
  function IGirl.PreferDolls=PreferDolls_g;
 
  end;
 
 
{ THermAphrodite }
 
procedure THermAphrodite.AfterConstruction;
begin
  inherited;
 FBoy:=TBoy.Create();
end;
 
function THermAphrodite.PreferDolls_g: boolean;
begin
  result:=true;//girl
end;
 
 
{ TBoy }
 
function TBoy.PreferDolls: boolean;
begin
 result:=false;//boy
end;
 
var i_chld:IChild;
    herm:THermAphrodite;
 
begin
  try
    { TODO -oUser -cConsole Main : Insert code here }
    herm:=THermAphrodite.Create();
    i_chld:= IBoy( herm );
    writeln('Prefer dolls(IChild from IBoy)',i_chld.PreferDolls);
    i_chld:= IGirl( herm );
    writeln('Prefer dolls(IChild from IGirl)',i_chld.PreferDolls);
 
 
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.
 
 

 
 
 
Добавлено:
ego666
 

Цитата:
   
не тупи, с предыдущей страницы вам уже два раза объясняли.
 
Вот пример как это может вылезти боком:
 
 
Подробнее...  

это неверно. Не боком!
 Как-раз нередко нужно скрыть подробности реализации, запретить клиенту создавать или финализировать сущности, а лишь пользоваться тем, что дают.
Это суть полиморфизма, и один из признаков профессионального кодирования.
Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 17:31 18-06-2013 | Исправлено: AlekXL, 17:52 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AlekXL
 
А в чем проблема? При неоднозначности - требовать уточнять какой именно интерфейс доставать! Типа IChild(IBoy()) или IChild(IGirl()). Компилятор то знает обо всех этих неоднозначностях. При этом - неоднозначность легко убирается путем уточнения (в существующем примере так и делается). А вот возможности достать из объекта родительский интерфейс при отсутствии неоднозначностей почему-то нету!  
 
upd: Имхо, класс THermAphrodite проще и понятнее записать так
Код:
 
 
  THermAphrodite=class(TInterfacedObject,IBoy,IGirl)
  public
    function PreferDolls_Yes: Boolean; // for girls
    function PreferDolls_No: Boolean; // for boys
 
    function IGirl.PreferDolls = PreferDolls_Yes;
    function IBoy.PreferDolls = PreferDolls_No;
  end;
 
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 17:57 18-06-2013 | Исправлено: deks, 18:04 18-06-2013
Eternal_Shield

Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
deks

Цитата:
Пока мне кажется, что в Дельфи использование наследования интерфейсов происходит через Ж. Абсолютно не вижу логики.  

Меня, пока что, не напрягает
 
Всего записей: 767 | Зарегистр. 18-05-2009 | Отправлено: 18:02 18-06-2013
AlekXL



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
А в чем проблема? При неоднозначности - требовать уточнять какой именно интерфейс доставать! Типа IChild(IBoy()) или IChild(IGirl()). Компилятор то знает обо всех этих неоднозначностях. При этом - неоднозначность легко убирается путем уточнения (в существующем примере так и делается).  
проблема в том, что Delphi - это все-таки не C++. Есть у Delphi пределы компетентности. Хотите блекджек и остальное - юзайте C++ Builder!
 
А еще - есть ленивые программисты, которые не хотят ворошить компилятор без крайней нужды. (Впрочем, неудивительно . Даже один из кодеров FPC высказывал свое ФЭ по поводу синтаксиса анонимов в Delphi - мол сложно реализовать парсер)
 
И, судя по всему - исходники компилятора Delphi внутри - это  гадюшник, клубок змей, где лучше ни к чему не прикасаться.  
 
 
Добавлено:

Цитата:
upd: Имхо, класс THermAphrodite проще и понятнее записать так  

нет. Гермафродит - редко такое случается.  А интерфейсы IBoy и IGirl - это обычное дело. И этих интефейсах может быть не один, а СТО один метод, реализовывать которые заново - это трудоемко и неправитьно.
 
Лучше унаследовать  THermaphordite скажем, от уже готовой реализации TGirl(IGirl) - и сделать агрегацию c TBoy.  
К сожалению, эта вкусняшка встречается лишь в Win компиляторе. Я ведь уже упоминал ленивых программистов?
Всего записей: 792 | Зарегистр. 24-04-2008 | Отправлено: 18:08 18-06-2013 | Исправлено: AlekXL, 18:14 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
AlekXL
 
Ну - мы то тут про конкретный пример к diamond problem (оно же "ромбовидное наследование"). А про способы, как в классе делать поддержку интерфейсов - да, есть куча удобных техник. И использование наследования (берем реализацию из класс-родителя), и делегирование реализации специальному member.  
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 18:28 18-06-2013
valgreesh



Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1

Цитата:
речь о том, что якобы интерфейсы обеспечили возможность использования win32  

Вау! Вот это фантазия... Воистину, каждый видит что хочет )
 

Цитата:
обеспечивается беспроблемный интероп с ... Objective C ... кодом

В фигурном цитировании упражняешься? Ок, но без меня.
Всего записей: 292 | Зарегистр. 30-11-2011 | Отправлено: 18:35 18-06-2013
Arioch1



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
компилятор ошибку ловит (не хватает реализации IPArent.P1).

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

Цитата:
В фигурном цитировании упражняешься

 
Вырезанное сделала утверждение менее сильным, полное утверждение потребовало бы еще и C++ кроме ObjC
 
Добавлено:

Цитата:
или мы не сможем достать родительский интерфейс из объекта!  

Ибо его там нет.
 
Мне иногда кажется, что главный глюу с интерфейсами был в GUID.
С одной стороны сказали, что тоьлко GUIDные интерфейсы поддерживают type safety, is & as
С другой стороны не запретили интерфейсы без GUIDа
 
В результате и получается то так то этак.
 
"Наследование" интерфейсов имеет не больше смысле, чем наследование record'ов и кроме удобства декларации в нём ничего не должно было бы быть.
Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 19:36 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1

Цитата:
или мы не сможем достать родительский интерфейс из объекта!  
 
Ибо его там нет.

 
Да вот фиг то там! Он есть - попробуйте объявить класс с поддержкой IChild и не объявить все реализации методов для IParent! Вот именно это обстоятельство мне и кажется нелогичным: компилятор при декларации требует методы родительского интерфейса реализовать, а вот каст не проходит. Да, ромбовидное наследование.. Но вот когда его нету - в чем проблема? У Оксигена такой проблемы нету.
 

Цитата:
главный глюу с интерфейсами был в GUID

 
Согласен. Я просто считаю, что главная ошибка была в смешивании понятий интерфейс и MS COM. На определенный период COM было круто (да и сейчас возможность рулить ms word/excel это сильно), но "фундаментальную" языковую фичу так жестко привязывать к win платформе - не айс. Лучше бы сделали "диалект" интерфейсов, заточенный строго под COM: со своим наследованием, и прочими прибамбасами платформы!  
 
Ну а про наследование интерфейсов - хз. Вроде бы практически удобная фича для всяких извратов архитектуры. Излишество? В какой то мере.. Но строго говоря все, что выше в абстракции чем asm - уже излишество той или иной степени!
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 20:37 18-06-2013 | Исправлено: deks, 20:38 18-06-2013
Arioch1



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Переменные IParent копируются в IChild, и этим переменным нужно назначить значение - ссылку на реализующий метод. Но это не значит, что присутствует сам IParent.
 

Цитата:
ошибка должна быть о нехватке IChild.P1

 
Просто добавь к ним всем GUIDы и подумай как в одном и том же поле IChild хранить сразу 2 (3? 4? ...) GUIDa для себя и для родителя.
 
Добавлено:
наследовать - по смыслу, вкладываемому в слово - можно поведение, т.е. реализацию, т.е. классы.
наследовать переменные - интерфейсы, record'ы - это оксюморон. Сами себя запутываем.
 

Цитата:
Вроде бы практически удобная фича для всяких извратов архитектуры

 
Это mix-ins из Питона и traits из Скалы, возможно и частичные классы.
Вроде бы это золотая середина позволяющая частично наследовать реализацию из нескольких классов  и не уткнуться в ромб. Полу-множественное наследование.
 
Но ее в Delphi нет.
Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 20:45 18-06-2013 | Исправлено: Arioch1, 20:50 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arioch1
 
Ну - чего и куда копируется это детали реализации. Главное, что класс TChild реализовал и IChild, и, соответственно IParent. Поэтому было бы логичным дать возможность достать из TChild искомый IParent напрямую!  
 
И, кстати, не совсем понял зачем в одном и том же поле хранить 2-3 значения? Если про способ реализации интерфейсов - то смотрим в сторону C++, там все давно расписано и с деталями реализации. Любое извращение найти можно))
 
Про наследование. Ну - не совсем согласен что для интерфейсов это оксюморон. Если относиться к интерфейсу как к протоколу, то по мне так логично будет расширять протокол дочерним протоколом, добавляющим какую-то специфику или новый слой функционала (HTTP -> WebDAV).
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 21:30 18-06-2013
delover

Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Да вот фиг то там! Он есть - попробуйте объявить класс с поддержкой IChild и не объявить все реализации методов для IParent!  

Немного не так. QueryInterface виртуальный метод. Я ничего вообще не объявлял, есть динамический TInterfaceList который я поддерживаю, то есть отдаю когда вы пишете as IIntf. В классе реализующем список восьмидесяти интерфейсов нет ни одного метода этих интерфейсов. Я их добавляю - удаляю из списка по усмотрению.

Код:
 
function TClassFoo.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
  Result := inherited QueryInterface(IID, Obj);
  if Result and $80000000 <> 0
  then Exit;
  if
    Assigned(QueryProc)
  then
    QueryProc(IID, Obj);
end;

Всего записей: 1395 | Зарегистр. 25-06-2007 | Отправлено: 21:40 18-06-2013 | Исправлено: delover, 21:42 18-06-2013
Arioch1



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Главное, что класс TChild реализовал и IChild, и, соответственно IParent.

 
да нет же!
 

Код:
 a := b  

 
а и b имеют одно значение, но это все равно разные переменные.
 
если в IChild входят несколько переменных, таких же как в IParent - это не делает их одним интерфейсом.
Всего записей: 904 | Зарегистр. 03-03-2010 | Отправлено: 22:03 18-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
delover
 
Вы мне рассказываете о деталях реализации интерфейсов на Win32, сделанных для совместимости с COM. Вспомним что еще бы GUID неплохо интерфейсу присвоить!)
 
Arioch1

Цитата:
это не делает их одним интерфейсом

 
В коде прямо написано "IChild = interface(IParent)" - что должно прямо делать их родительским интерфейсом и дочерним. Дельфи выбрало путь сожительства интерфейсов с COM, а наследование интерфейсов так себе сочетается с COM. Отсюда и все обсуждаемые сложности)))
 
Я не против текущего решения с интерфейсами в Дельфи, я даже понимаю почему именно это так. Просто это такой не очень логичный и местами не очень удобный динозавр)) Жить с этим можно!  
 
Ну и важно - в этом случае "особенности" интерфейсов дельфи имеют довольно понятные причины. В отличие от особенностей реализации TList<>
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 22:23 18-06-2013 | Исправлено: deks, 22:24 18-06-2013
ego666

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Не IDispatch ли решает подобную проблему .. по типу той, что в примере? ...

Неее, ну его нафиг делать это через IDispatch.
 

Цитата:
и как сие попадает под определение, что родитель должен знать о всех методах всех своих наследников?

Эмм.. да я такого и не говорил и даже такого нигде не подразумевал.
 

Цитата:
В нашем случае, как IList может знать о методах в своих наследниках IFileFile, IStreamList и т.п.? С какого перепугу vtbl родителя изменится, чтобы отразить методы его наследников? ...  

Ты меня наверное не понял, покажи в моём коде что ты имеешь ввиду? (и я тебе покажу, что я другое имею ввиду)
 
Добавлено:

Цитата:
Хм. Тогда переспрошу - а чем принципиально отличаются интерфейсы C#/Java от Delphi?

http://docwiki.embarcadero.com/RADStudio/XE2/en/Object_Interfaces_Index
 

Цитата:
Пока мне кажется, что в Дельфи использование наследования интерфейсов происходит через Ж. Абсолютно не вижу логики.  

Чукча не читатель?
http://forum.ru-board.com/topic.cgi?forum=33&topic=13680&start=357&limit=1&m=1#1
http://forum.ru-board.com/topic.cgi?forum=33&topic=13680&start=374&limit=1&m=1#1
 
Добавлено:

Цитата:
WTF! - нелогично же. Зачем так сделано? Понимаю все проблемы COM, но это ж прошлый век! Даже голимый C# от этого ушел!

Интерфейсы в COM спроектировали очень грамотно, вдумываясь учли все возможные нюансы.
А вот в Шарпе (и подобных) их тупо, не думая, слепили из абстрактных классов.
 
Добавлено:

Цитата:
По поводу примера с IList и IFileList. А с какого перепуга мы достаем из объекта интерфейс IList и пытаемся работать с ним как с IFileList?

Покажи кодом, где я достаю IList и работаю с ним как с IFileList?
 

Цитата:
Когда же предок позволял работать с собой как с потомком?

Где это в моём коде?
 
Ещё раз вдумчиво посмотри пример (ссылка выше).
 
Добавлено:

Цитата:
Как-раз нередко нужно скрыть подробности реализации, запретить клиенту создавать или финализировать сущности, а лишь пользоваться тем, что дают.

Ситуации бывают разные.
 
Добавлено:

Цитата:
  THermAphrodite=class(TInterfacedObject,IBoy,IGirl)
    public
      function PreferDolls_Yes: Boolean; // for girls
      function PreferDolls_No: Boolean; // for boys
 
      function IGirl.PreferDolls = PreferDolls_Yes;
      function IBoy.PreferDolls = PreferDolls_No;     
  end;

Скрестил ужа с ежом. И что по твоему должен вернуть метод PreferDolls, если бы ты кастанул объект  к IParent?
 
Добавлено:
правильный ответ:
из объекта вообще нельзя получать интерфейс IParent, если только мы его явно не указали и не реализовали в классе объекта, ключевое слово явно, т.к. конкретно в этой ситуации, с IBoy и IGirl, IParent ну не нужно и нельзя получать из объекта, реализующего оба этих наследника.
 
Добавлено:

Цитата:
Да вот фиг то там! Он есть - попробуйте объявить класс с поддержкой IChild и не объявить все реализации методов для IParent! Вот именно это обстоятельство мне и кажется нелогичным: компилятор при декларации требует методы родительского интерфейса реализовать, а вот каст не проходит.

Потому что в интерфейсах наследуется интерфейс, не реализация как в наследовании классов, а интерфейс, который можно реализовать как угодно, не оглядываясь на родителя. Для IGirl реализовывает все методы IParent по своему, для IBoy - по своему.
 
Добавлено:

Цитата:
Я просто считаю, что главная ошибка была в смешивании понятий интерфейс и MS COM.

Ты можешь как угодно считать? В то время, по крайней мере, Delphi разрабатывали не дураки. Если именно так сделали, значит именно так и нужно было делать.
 
Добавлено:
Ты можешь как угодно считать. (тут без знака вопроса, боюсь править пост - опять свернётся)
 
Добавлено:

Цитата:
В коде прямо написано "IChild = interface(IParent)" - что должно прямо делать их родительским интерфейсом и дочерним.

для классов свои правила, для интерфейсов - свои, не надо их равнять между собой, правила классов неприменимы к интерфейсам, потому что там наследуются реализации и наследник класса обязан "поддерживать" родителя, а интерфейсов фактически ничего не наследуется и его ничто не обязывает "поддерживать" родителя.
Всего записей: 77 | Зарегистр. 14-06-2013 | Отправлено: 07:24 19-06-2013
deks



Advanced Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
ego666
 

Цитата:
Покажи кодом, где я достаю IList и работаю с ним как с IFileList?  

 
var List: IList;
..
 
 List := TFileList.Create; // достаем IList из TFileList
..
А вот тут пытаемся работать с IList с помощью методов определенных для IFileList:
  List.Open(...) //<- ошибка, в IList нет метода Open  
 
 
 
Добавлено:

Цитата:
интерфейс, который можно реализовать как угодно, не оглядываясь на родителя

 
Я же говорю не со стороны реализации, а со стороны использования! Если дочерний интерфейс реализует все методы родительского - то в чем проблема кастануть его к родительскому? Одну проблему уже указали - diamond problem. Имхо, она легко решается уточнением.  
 

Цитата:
В то время

 
Времена меняются))
 

Цитата:
наследник класса обязан "поддерживать" родителя

 
No. Все ровно наоборот: наследник класса вообще не обязан ничего с родителем делать. "TChild = class(TParent) end; " - это полностью готовый к использованию валидный класс, который включает в себя и декларацию, и реализацию. Обращаем внимание - наследник ничего не делает для поддержки родителя.  
 
У интерфейсов декларация в одном месте, реализация в другом. Если с декларацией все абсолютно так же как и с классами, то с реализацией чуть сложнее. требуется полностью реализовать все методы: и ЯВНО поддерживаемого интерфейса, и РОДИТЕЛЬСКОГО интерфейса.  
 
Однако речь шла не о реализации, а ОБ ИСПОЛЬЗОВАНИИ интерфейсов. Вот тут мне до сих пор непонятен вопрос - почему есть проблемы с кастом до родительского интерфейса в очевидных случаях. У части "альтернативных паскалей" такой проблемы нету.
 

Цитата:
Хм. Тогда переспрошу - а чем принципиально отличаются интерфейсы C#/Java от Delphi?
http://docwiki.embarcadero.com/RADStudio/XE2/en/Object_Interfaces_Index  
 

 
Чего уж - сразу на Гугл ссылку давать надо)) Но на самом деле - если по существу сказать нечего, лучше промолчать, за умного сканаешь!
Всего записей: 857 | Зарегистр. 09-10-2003 | Отправлено: 09:19 19-06-2013
X11



Silver Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Информация по разработке для мобильных систем
 
The Delphi Language for Mobile Development - техническая статья Марко Канту - PDF
http://img.en25.com/Web/Embarcadero/%7B9993955a-d923-4d02-8f00-0ac860d08556%7D_delphilanguagemobiledevelopmentwhitepaper170413.pdf
 
Обучающие материалы по разработке для iOS
http://docwiki.embarcadero.com/RADStudio/XE4/en/IOS_Tutorials:_Delphi_iOS_Application_Development?elq=db7ea77a14064544978abeea8902e832&elqCampaignId=187

----------
/не мы такие, жизнь такая/
Всего записей: 3253 | Зарегистр. 24-11-2005 | Отправлено: 10:21 19-06-2013
ego666

Junior Member		Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
var List: IList;  
 ..  
   
  List := TFileList.Create; // достаем IList из TFileList  
 ..  
 А вот тут пытаемся работать с IList с помощью методов определенных для IFileList:  
   List.Open(...) //<- ошибка, в IList нет метода Open  

Вот именно, что при текущем положении вещей, я не смогу достать IList из TFileList, а если бы мог - то не смог правильно с ним работать, ведь у него нет необходимых из IFileList, которые нужно обязательно вызывать.
 

Цитата:
Одну проблему уже указали - diamond problem. Имхо, она легко решается уточнением.  

Проблему ромба ты не решил. Другая проблема - ох... эта та о которой я уже талдычу последние N страниц.
 
Добавлено:

Цитата:
No. Все ровно наоборот: наследник класса вообще не обязан ничего с родителем делать. "TChild = class(TParent) end; " - это полностью готовый к использованию валидный класс, который включает в себя и декларацию, и реализацию. Обращаем внимание - наследник ничего не делает для поддержки родителя.

Лукавишь. Принцип подстановки Лисков.
 
Добавлено:
А именно:

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


Цитата:
подкласс не должен требовать от вызывающего кода больше, чем базовый класс, и не должен предоставлять вызывающему коду меньше, чем базовый класс

Это справедливо для классов, только для классов, т.к. у них идёт наследование реализации.
Это не относится к интерфейсам, т.к. у них нет наследования реализации и не нужно к ним применять эти правила, во-первых - это выйдет боком, во-вторых - бессмысленно.
 
Добавлено:

Цитата:
У части "альтернативных паскалей" такой проблемы нету

Потому что они просто не задумывались, в отличии от проектировщиков COM.
Всего записей: 77 | Зарегистр. 14-06-2013 | Отправлено: 10:51 19-06-2013 | Исправлено: ego666, 10:52 19-06-2013
Открыть новую тему     Написать ответ в эту тему

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

Компьютерный форум Ru.Board » Компьютеры » Прикладное программирование » Вопросы по Embarcadero RAD Studio XE4


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru