Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата Romkin @ 03.11.11, 07:28

Приватны для объекта, публичны для интерфейса.

т.е. собственный интерфейс класса меняется в зависимости от способа обращения? супер...

Цитата Romkin @ 03.11.11, 07:28

Просто интерфейс надо рассматривать не как абстрактное описание, а как отдельную сущность.

интерфейс и есть абстрактное описание, в этом его сущность.

Цитата Romkin @ 03.11.11, 07:28

Объект реализует интерфейс, а не обладает интерфейсом.

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

Цитата Romkin @ 03.11.11, 07:28

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

клиент _всегда_ работает с объектом через интерфейс (публичные методы), и если класс декларирует, что реализует какой-то интерфейс, то его собственный интерфейс должен включать реализуемый.

Цитата Romkin @ 03.11.11, 07:28

Преимущество в том, что при этом прямо в коде указывается и документируется способ работы с данными объектами.

как это вообще относится к вопросу и в чем именно заключается преимущество? а в джаве/шарпе не указывается?

Цитата DesweR @ 03.11.11, 07:42

Там тоже самое написано (это я писал, если что).

Где там?

Цитата DesweR @ 03.11.11, 07:42

Верно.

Что верно? Там как раз написано, что у тебя неверно, нужно чтобы TBC1 реализовывал все IB, IC, IA интерфейсы. А у тебя реализованы только два!

Цитата scorpion @ 03.11.11, 07:41

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

А зачем вообще они тебе нужны в паблике? Лишний раз поддаваться искушению заюзать объект реализации?

Цитата DesweR @ 03.11.11, 07:44

А зачем вообще они тебе нужны в паблике? Лишний раз поддаваться искушению заюзать объект реализации?

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

Цитата scorpion @ 03.11.11, 07:43

Там как раз написано

"Там" писал я, пол года назад, если что...

Цитата scorpion @ 03.11.11, 07:43

что у тебя неверно, нужно чтобы TBC1 реализовывал все IB, IC, IA интерфейсы.

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

Добавлено 03.11.11, 07:50

Цитата scorpion @ 03.11.11, 07:37

Ггг... Во первых, что ты собрался делать с интерфейсом, не известным на этапе компиляции? Во вторых, как с ним работать, и какие методы у него вызывать? в третьих, как пользователь из gui будет его гдето регистрировать и определять доступные реализации? Оно вообще, пользователю нужно? Что за бред вообще ты несешь?

Сообщение отредактировано: DesweR - 03.11.11, 07:50

Цитата MyNameIsIgor @ 03.11.11, 07:32

Наоборот - это как? Работающий с реализацией не знает, что она реализует? Отдаёт бредом...

А с реализацией он работает с другим функционалом. Знает, конечно, но использовать этот функционал он может только через интерфейс, в качестве дополнительного. Это разделение, которое упрощает связи в коде. Один блок работает с объектом, другой - с конкретным интерфейсом.

Цитата Romkin @ 03.11.11, 07:54

А с реализацией он работает с другим функционалом. Знает, конечно, но использовать этот функционал он может только через интерфейс

Тогда как происходит сокрытие, если всё доступно через интерфейс?

Цитата DesweR @ 03.11.11, 07:36

Имея только интерфейс IGuest, ты не сможешь сделать то, что доступно только IAdmin.

o'really?

program Test;
 
{$APPTYPE CONSOLE}
 
uses
  SysUtils;
 
type
  IGuest = interface
    procedure foo;
  end;
 
  IAdmin = interface
    procedure bar;
  end;
 
  TUser = class(TInterfacedObject, IAdmin, IGuest)
  private
    procedure foo;
    procedure bar;
  end;
 
procedure TUser.foo;
begin
  WriteLn('foo');
end;
 
procedure TUser.bar;
begin
  WriteLn('bar');
end;
 
procedure adminAction(admin: IAdmin);
begin
  admin.bar;
end;
 
procedure guestAction(guest: IGuest);
begin
  guest.foo;
  if guest is TUser then
  adminAction(guest as TUser);
end;
 
 
 
var
  user: TUser;
 
begin
  user := TUser.Create;
 
  try
    guestAction(user);
    //adminAction(user);
    ReadLn;
  except
    on E: Exception do begin
      Writeln(E.ClassName, ': ', E.Message);
      ReadLn;
    end;
  end;
end.

Цитата DesweR @ 03.11.11, 07:48

"Там" писал я, пол года назад, если что...

Какая разница кто там и когда писал. Зачем ты тогда это сюда цитировал?

Цитата DesweR @ 03.11.11, 07:48

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

Речь о том, что если у тебя есть интерфейс IA, от которого наследуются два интерфейса IB и IC, и есть объект, который реализует только интерфейсы IB и IC, но не реализует IA, то использование интерфейса IA, может привести к крешу программы(или ошибке на этапе компиляции?). И в этом случае либо нужно будет явно реализовывать IA, либо вообще зачем он нужен тогда, если его никто не реализует?

Добавлено 03.11.11, 08:01

Цитата DesweR @ 03.11.11, 07:48

Самому смешно?

Цитата korvin @ 03.11.11, 07:42

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

Почему?
Класс может и не содержать реализация в виде "таких же методов", она может быть агрегирована вложенным объектом.

Цитата Romkin @ 03.11.11, 07:54

А с реализацией он работает с другим функционалом. Знает, конечно, но использовать этот функционал он может только через интерфейс, в качестве дополнительного. Это разделение, которое упрощает связи в коде. Один блок работает с объектом, другой - с конкретным интерфейсом.

А если я хочу расширить функциональность, допустим отнаследоватся от класса, который уже реализует интерфейсы, и при этом у него все методы расположены в закрытой секции(private). То как я его расширю? Допустим, я хочу немножко изменить функциональность одного из методов. Ну например добавить возможность логирования, но не хочу реализовывать это непосредственно в классе, реализующем интрефейс. Что тогда? Опана - приплыли? Доступа к методам класса, реализующего интерфейс у нас нетути...?

Сообщение отредактировано: scorpion - 03.11.11, 08:05

Цитата korvin @ 03.11.11, 07:59

o'really?

Это жёсткий каст, не считается

Сообщение отредактировано: DesweR - 03.11.11, 08:07

Цитата DesweR @ 03.11.11, 08:02

Класс может и не содержать реализация в виде "таких же методов", она может быть агрегирована вложенным объектом.

какая разница? суммарный интерфейс Класса должен включать интерфейс Интерфейса (простите за тафтологию =))

Добавлено 03.11.11, 08:13

Цитата DesweR @ 03.11.11, 08:07

Это жёсткий каст, не считается

а че это вдруг не считается? админский метод вызывает из гостевой функции и никто этому не мешает

Цитата scorpion @ 03.11.11, 07:59

Речь о том, что если у тебя есть интерфейс IA, от которого наследуются два интерфейса IB и IC, и есть объект, который реализует только интерфейсы IB и IC, но не реализует IA, то использование интерфейса IA, может привести к крешу программы

Нет, в таком случае интерфейс IA ты просто не получишь из объекта.

я вам даже больше скажу, если в приведенном мною коде поменять в определении класса TUser private на public, то поведение программы и компилятора не изменится