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

Цитата IL_Agent @ 14.03.11, 09:26

В C# это не так. При реализации придётся явно указать, от какого интерфейса взят метод.

void InterfaceName.MethodName(int a)
{...}

т.е. нужно реализовывать два метода? А как выглядит вызов этих методов?

Цитата DesweR @ 14.03.11, 08:36

MyNameIsIgor
А что у тебя выведется при таком варианте?

var
  a: A;
  b: B;
begin
  a := A.Create;
  a.f;
 
  b := B.Create;
  b.f;
 
  a := B.Create;
  a.f;
end;

Строго говоря, у класса B нет метода f. Можно рассмотреть такой код

#include <iostream>
 
class IA
{
public:
  virtual void f() = 0;
};
 
class IB : public IA
{
public:
  virtual void g() = 0;
};
 
class A : public IA
{
public:
  virtual void f() { std::cout << "A::f()" << std::endl; }
};
 
class IB2 : public IB
{
  void f() { IB_f(); }
public:
  virtual void IB_f() = 0;
};
 
class B : public A, public IB2
{
public:
  virtual void g() { std::cout << "B::g()" <<std::endl; }
  virtual void IB_f() { std::cout << "B::f()" <<std::endl; }
};
 
int main()
{
  A a;
  a.f();
 
  B b;
  b.IB_f();
  b.g();
 
  return 0;
}

С выводом

A::f()
B::f()
B::g()

Добавлено 14.03.11, 10:23

Цитата korvin @ 14.03.11, 09:43

Цитата IL_Agent @ 14.03.11, 09:26

В C# это не так. При реализации придётся явно указать, от какого интерфейса взят метод.

void InterfaceName.MethodName(int a)
{...}

т.е. нужно реализовывать два метода? А как выглядит вызов этих методов?

Например, так

using System;
 
interface IA
{
  void f();
}
 
interface IB
{
  void f();
}
 
class A : IA, IB
{
  void IA.f() { Console.WriteLine("IA.f"); }
  void IB.f() { Console.WriteLine("IB.f"); }
}
 
class Program
{
  public static void Main(string[] args)
  {
    A a = new A();
    (a as IA).f();
    (a as IB).f();
  }
}

Цитата D_KEY @ 14.03.11, 08:59

Если рассматривать классы, то С++ удовлетворяет критериям. А отдельного понятия "модуль" в С++ нет

Если конечно не ошибаюсь, но в Eiffel "один класс" = "один файл/модуль".

Цитата DesweR @ 14.03.11, 10:39

Цитата D_KEY @ 14.03.11, 08:59

Если рассматривать классы, то С++ удовлетворяет критериям. А отдельного понятия "модуль" в С++ нет

Если конечно не ошибаюсь, но в Eiffel "один класс" = "один файл/модуль".

А причем тут файлы? Файлы - это физическое размещение текста программы. Мы же говорили о логике.
Модуль - логическая единица программы. Пространство имен/пакет/"кластер"(Eiffel) - механизм логического объединения.
Файл /= модуль

Добавлено 14.03.11, 11:42

Цитата Qraizer @ 14.03.11, 03:13

Цитата korvin @ 13.03.11, 15:53

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

Ну, первое не проблема. А вот второе - категорическое нет. Это методы разных интерфейсов. С какого перепуга они окажутся одним и тем же? Имена совпали? Бывает. Кто виноват? Да никто.

Как это никто? Разработчики. Теоретически разные интерфейсы не должны иметь одинаковых имен с разным смыслом.
В этом есть разница между интерфейсами и абстрактными классами. Интерфейсы не описывают абстрактный тип данных, они описывают именно набор операций.
Хотя я понимаю, что на практике такие коллизии бывают и их нужно разруливать, но это не от хорошей жизни.

Добавлено 14.03.11, 11:44

Цитата DesweR @ 14.03.11, 05:35

К слову спросить, а в C# есть ли дизайн классов по контракту? В Oxygene (Delphi Prism) есть
http://prismwiki.codegear.com/en/Class_Contracts

Есть, но по сравнению с Eiffel не так удобен. Разработчики на Eiffel уверяют, что они просто чувствуют себя обязанными написать инварианты, пред и пост условия
А так и для С++ есть...

Сообщение отредактировано: D_KEY - 14.03.11, 11:44

Цитата Qraizer @ 14.03.11, 03:13

Зато Shaggy лишён возможности наследовать готовые реализации ITCP и IHistory, написанные с год назад для разных проектов.

безосновательное утверждение...

Добавлено 14.03.11, 12:21

Цитата D_KEY @ 14.03.11, 11:36

Теоретически разные интерфейсы не должны иметь одинаковых имен с разным смыслом.

это почему?

Цитата Shaggy @ 14.03.11, 12:19

Цитата D_KEY @ 14.03.11, 11:36

Теоретически разные интерфейсы не должны иметь одинаковых имен с разным смыслом.

это почему?

Зачем нескольким интерфейсам иметь два одинаковых метода с совершенно разным предполагаемым(и никак неотраженным в контракте) поведением?
Код должен стремится к самодокументированию и из названия метода должно быть полностью понятно, ЧТО он делает(реализация же определяет КАК).
Если уж вам нужен метод "время жизни", то он должен иметь один смысл("время жизни того объекта, для которого я его вызываю"), в противном случае название выбрано не верно.

Цитата D_KEY @ 14.03.11, 12:31

Код должен стремится к самодокументированию и из названия метода должно быть полностью понятно, ЧТО он делает(реализация же определяет КАК).

ты почему-то рассмариваешь метод как отдельную сущьность
есть же ещё интерфейс(имя), namespace, если угодно
interfaceName.methodName - вполне себе понятно что он делает...

Цитата D_KEY @ 14.03.11, 12:31

Зачем нескольким интерфейсам иметь два одинаковых метода с совершенно разным предполагаемым(и никак неотраженным в контракте) поведением?

interface IIntList
{
   void Add(int value);
}
 
interface INumber
{
   void Add(int value);
}

Цитата Shaggy @ 14.03.11, 12:49

Цитата D_KEY @ 14.03.11, 12:31

Код должен стремится к самодокументированию и из названия метода должно быть полностью понятно, ЧТО он делает(реализация же определяет КАК).

ты почему-то рассмариваешь метод как отдельную сущьность
есть же ещё интерфейс(имя), namespace, если угодно

Потому, что единственное логическое отличие интерфейса от абстрактного класса заключается в том, что интерфейс не обязан описывать абстрактный тип - он описывает именно набор операций. В противном случае, почему бы не воспользоваться абстрактными классами?
Пространством имен интерфейсы тем более считать не стоит.
ИМХО.

Цитата

interfaceName.methodName - вполне себе понятно что он делает...

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

Добавлено 14.03.11, 13:10
jack128, ИМХО, List "не правильный". Тем более, в качестве интерфейса. В любом случае, это "один и тот же" метод - "добавь к моему объекту значение int". Какие конфликты?

Цитата Shaggy @ 14.03.11, 12:49

ты почему-то рассмариваешь метод как отдельную сущьность
есть же ещё интерфейс(имя), namespace, если угодно
interfaceName.methodName - вполне себе понятно что он делает...

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

Цитата korvin @ 14.03.11, 13:26

Цитата Shaggy @ 14.03.11, 12:49

ты почему-то рассмариваешь метод как отдельную сущьность
есть же ещё интерфейс(имя), namespace, если угодно
interfaceName.methodName - вполне себе понятно что он делает...

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

Не забывай, что в обсуждаемых языках(ну кроме С++) интерфейсы нужны в качестве костыля для обеспечения множественного наследования

Сообщение отредактировано: D_KEY - 14.03.11, 13:35

Цитата D_KEY @ 14.03.11, 13:07

А безымянных интерфейсов не может быть?

пример?

Цитата korvin @ 14.03.11, 13:26

интерфейсы лишь способ описать множество методов, пространства имен они не создают, их создают классы

хм...

Цитата Shaggy @ 14.03.11, 13:37

Цитата D_KEY @ 14.03.11, 13:07

А безымянных интерфейсов не может быть?

пример?

На некотором абстрактном языке:

f(interface { f(self, int)->int } object, int x) -> int
{
    //...
    return object.f(10)
}

Цитата

Цитата korvin @ 14.03.11, 13:26

интерфейсы лишь способ описать множество методов, пространства имен они не создают, их создают классы

хм...

А что, не так-то?

Цитата D_KEY @ 14.03.11, 13:35

Не забывай, что в обсуждаемых языках(ну кроме С++) интерфейсы нужны в качестве костыля для обеспечения множественного наследования

слайды! слайды!
приведи пример(и желательно не один) в котором интерфейсы используются именно в таком качестве...

Добавлено 14.03.11, 13:47

Цитата D_KEY @ 14.03.11, 13:42

На некотором абстрактном языке:

ничего непонял...
а на каком-то реальном языке можно?

Цитата Shaggy @ 14.03.11, 13:44

Цитата D_KEY @ 14.03.11, 13:35

Не забывай, что в обсуждаемых языках(ну кроме С++) интерфейсы нужны в качестве костыля для обеспечения множественного наследования

слайды! слайды!
приведи пример(и желательно не один) в котором интерфейсы используются именно в таком качестве...

В каком таком? Ты никогда не наследовал один класс от нескольких интерфейсов?

Цитата

Цитата D_KEY @ 14.03.11, 13:42

На некотором абстрактном языке:

ничего непонял...
а на каком-то реальном языке можно?

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

Сообщение отредактировано: D_KEY - 14.03.11, 13:51