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

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

а теперь то же самое для delphi, только child и parent интерфейсы
результат: incompatible types

А почему, кстати? Не в смысле языка, а в смысле логики. Если child публично наследует - именно наследует!, а не агрегирует! - parent, то он в частности является parent. Иначе какой толк в таком наследовании. Значит child расширяет parent, т.е. может содержать что-то своё помимо, но унаследованное оставляется у себя в неизменном виде. Теперь если A реализует интерфейс child, почему это он при этом не реализует и интерфейс parent? Иначе с какой стати incompatible types? Другое дело если наследование непубличное или его нет вообще. Но ведь мы о публичном, ведь так?

Добавлено 14.03.11, 23:33
О, D_KEY вон тоже инетерсуется.

Добавлено 14.03.11, 23:35
Теперь, думаю, понятно, почему мне кажется костылём использование агрегации в качестве замены множественному наследованию реализаций при публичном множественном наследовании интерфейсов. Ну это так, к слову о прошлых постах.

такой еще вопрос возник (ко всем):

// допустим есть класс
class Int {
    private int x = 0;
 
    public int get () {
        return x;
    }
    public void set (int x) {
        this.x = x;
    }
 
    X (int x) {
        this.x = x;
    }
}
 
// и класс
class C {
    Int x = new Int();
}

можно ли в C как-то предоставить доступ к C.x.set и C.x.get, но не к самому C.x (т.е. нельзя вернуть сам объект C.x, но применить к нему его методы -- можно) без создания методов getX, setX в классе C?

korvin, в плюсах это возможно, если воспользоваться приватным наследованием

#include <iostream>
 
class Int
{
  int x_;
public:
  Int() : x_(0) {}
  Int(int x) : x_(x) {}
  int get() const { return x_; }
  void set(int x) { x_ = x; }
};
 
class C : Int
{
public:
  C() : Int() {}
  C(int x) : Int(x) {}
  using Int::get;
  using Int::set;
};
 
int main()
{
  C c;
  std::cout << c.get() << std::endl;
  c.set(10);
  std::cout << c.get() << std::endl;
}

Цитата korvin @ 15.03.11, 05:02

нельзя вернуть сам объект C.x, но применить к нему его методы -- можно

Это как?

Цитата

без создания методов getX, setX в классе C?

А как ты хотел бы? Пример можно?
Кстати, про "закон Деметры" не слышал ?

Цитата D_KEY @ 15.03.11, 05:31

Это как?

А как ты хотел бы? Пример можно?
Кстати, про "закон Деметры" не слышал ?

как я хотел бы, я написал: C.x.get -- обратиться к интерфейсу x можно, а C.x -- получить сам объект нельзя.
Что за закон?

Игорь, не катит: в C может быть несколько объектов типа Int, а в Int может быть довольно много методов

Цитата korvin @ 15.03.11, 05:44

Игорь, не катит: в C может быть несколько объектов типа Int, а в Int может быть довольно много методов

Если их там несколько, то к которому их них будет применяться get и set?
И что, что много методов? Вас не устраивает, что для каждого надо писать using?

Сообщение отредактировано: MyNameIsIgor - 15.03.11, 05:46

Цитата MyNameIsIgor @ 15.03.11, 05:46

Если их там несколько, то к которому их них будет применяться get и set?
И что, что много методов? Вас не устраивает, что для каждого надо писать using?

я же написал: c.x.get -- вызывается get для x, соответственно c.y.get -- для y

Так вам важен синтаксис? Или вызов метода агрегированного объекта без доступа к этому объекту?

Цитата MyNameIsIgor @ 15.03.11, 06:07

Так вам важен синтаксис? Или вызов метода агрегированного объекта без доступа к этому объекту?

дело не в синтаксисе, а в отсутствии необходимости писать методы-обертки для каждого метода каждого такого внутреннего объекта

Цитата korvin @ 15.03.11, 06:22

дело не в синтаксисе, а в отсутствии необходимости писать методы-обертки для каждого метода каждого такого внутреннего объекта

Необходимо ли указывать, как каким методам внутреннего объекта будет иметь доступ внешний код?

Сообщение отредактировано: MyNameIsIgor - 15.03.11, 06:26

Цитата korvin @ 15.03.11, 05:44

Цитата D_KEY @ 15.03.11, 05:31

Это как?

А как ты хотел бы? Пример можно?
Кстати, про "закон Деметры" не слышал ?

как я хотел бы, я написал: C.x.get -- обратиться к интерфейсу x можно, а C.x -- получить сам объект нельзя.

Чем для тебя отличается обращение к интерфейсу x от получения "самого" объекта?

Цитата

Что за закон?

Law_of_Demeter

Добавлено 15.03.11, 06:31

Цитата korvin @ 15.03.11, 06:22

Цитата MyNameIsIgor @ 15.03.11, 06:07

Так вам важен синтаксис? Или вызов метода агрегированного объекта без доступа к этому объекту?

дело не в синтаксисе, а в отсутствии необходимости писать методы-обертки для каждого метода каждого такого внутреннего объекта

Что-то у тебя объекты похоже больше на структуры

Цитата korvin @ 15.03.11, 05:44

C.x.get -- обратиться к интерфейсу x можно

А кто определяет, к каким методам x обратиться можно, а к каким нельзя?
И потом, если C должен иметь подможество интерфейса x, не проще ли унаследоваться от x и не заморачиваться?

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

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

В Eiffel это (файл = модуль) фактически выглядит именно так, кстати там нет пространства имём и, если я не ошибаюсь, наименования классов в системе должны быть уникальными.
Для логической группировки в Eiffel используются кластеры и такого же эффекта можно с легкостью и в Delphi добиться. Вообще не важно, является ли модуль физическим или логическим представлением текста программы, важна сама логическая композиция схожих по задачам модулей.

P.S.
На порядок удобнее, когда наименование логического интерфейса подключения модуля совпадает с физическим наименованием этого модуля

Цитата Qraizer @ 14.03.11, 15:10

Это разные интерфейсы, один ведёт ограниченную по времени историю общения, второй - обменивается пакетами по инету. С какого перепуга у них обязан быть один автор? Их понадобилось свести в один компонент, чтобы по сети беседовать с собеседником. Что, теперь автору этого нового компонента нельзя их использовать совместно? В С++ можно, значит он плохой язык? Ну да, в Дельфи такая объектная модель, что аж приличных слов не хватает.

С какого перепугу вообще тогда возникла необходимость сводить их в один класс? ИМХО тут как раз место агрегации.

Цитата Qraizer @ 14.03.11, 15:10

Гм. А вот ответь, пожалуйста, каковы критерии позиционирования как "множествено-наследуемости"? Неужели среди них будут имена методов?

Если ты умышленно об этом не заботишься - ты ССЗБ.

Цитата Qraizer @ 14.03.11, 15:10

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

"Корифеи" есть:
http://ru.wikipedia.org/wiki/Агрегирование_(программирование)

Цитата Qraizer @ 14.03.11, 15:10

Вот именно. Никто не будет обвинять C-программера, что для внешней функции своей библиотеки выбрал имя, совпадающее с именем другой функции другой библиотеки, если они обе понадобятся в одной программе. Так же, как никто не будет утверждать, что это теперь должна быть одна и та же функция. А вот решать эту коллизию придётся. Дельфи сливает функции в одну, korvin утверждает, что это нормально, DesweR, что виноват я, а ты - что виноваты авторы библиотек. И только C++ предлагает несложные пути решения коллизий "имеющимися средствами".

Если забыл, в Delphi есть штатные средства для решения таких коллизий.

Цитата Qraizer @ 14.03.11, 15:10

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

?

Цитата D_KEY @ 14.03.11, 19:57

Еще раз прошу пояснить мне, в чем тогда принципиальная концептуальная разница между интерфейсом и абстрактным классом?

Опять по кругу? N страниц назад уже пояснялось и приводились задачи, где вам чтобы добиться схожего поведения, приходилось городить огороды костылей.

Цитата Qraizer @ 14.03.11, 23:32

А почему, кстати? Не в смысле языка, а в смысле логики. Если child публично наследует - именно наследует!, а не агрегирует! - parent, то он в частности является parent. Иначе какой толк в таком наследовании. Значит child расширяет parent, т.е. может содержать что-то своё помимо, но унаследованное оставляется у себя в неизменном виде. Теперь если A реализует интерфейс child, почему это он при этом не реализует и интерфейс parent? Иначе с какой стати incompatible types? Другое дело если наследование непубличное или его нет вообще. Но ведь мы о публичном, ведь так?

Это отчасти вытекает из идеологии COM'а, интерфейс - это абстрактный протокол, который описывает только взаимодействие с объектом и не содержит детали его реализации. Возьмём класс X, реализующий некоторый функционал, класс X могут наследовать несколько других классов XA, XB, XC, в этом случае они наследуют и расширяют функционал родительского класса X, но никак его не замещают и не ограничивают, работает принцип подстановки Лисков, мы можем создать объект любого из дочерних классов, привести его к базовому и спокойно работать. Теперь возьмём интерфейс Y, описывающий некоторый абстрактный протокол, этот интерфейс могут реализовывать несколько классов YA, YB, YC, в этом случае они "наследуют" и реализовывают протокол взаимодействия и т.к. никакой базовой реализации у интерфейса нет - YA, YB, YC реализовывают протокол взаимодействия полностью сами, при этом теперь никем не гарантируется, что будет работать принцип подстановки Лисков, даже несмотря на схожесть сигнатур интерфейса, семантика его реализаций может быть различной (собственно в COM даже рекомендуется давать наименования методам с неопределённым смыслом, чтобы каждая реализация интерфейса могла их интерпретировать по своему). Тоже самое касается и наследования интерфейсов, должен соблюдаться не только сигнатурный контракт, но и гарантированно семантический, а для этого класс A, должен содержать реализацию интерфейсов и child и parent.

Цитата DesweR @ 15.03.11, 06:43

P.S.
На порядок удобнее, когда наименование логического интерфейса подключения модуля совпадает с физическим наименованием этого модуля

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

Цитата

Цитата Qraizer @ 14.03.11, 15:10

Это разные интерфейсы, один ведёт ограниченную по времени историю общения, второй - обменивается пакетами по инету. С какого перепуга у них обязан быть один автор? Их понадобилось свести в один компонент, чтобы по сети беседовать с собеседником. Что, теперь автору этого нового компонента нельзя их использовать совместно? В С++ можно, значит он плохой язык? Ну да, в Дельфи такая объектная модель, что аж приличных слов не хватает.

С какого перепугу вообще тогда возникла необходимость сводить их в один класс? ИМХО тут как раз место агрегации.

Зависит от дизайна этих классов. Если они предоставляют каркас поведения, давая потомкам специализировать лишь некоторые аспекты поведения(например, см. паттерн "шаблонный метод"), то без наследования ты вряд ли что-то сможешь полезное сделать. В Java это частично решается через inner-классы, как в Delphi и шарпе - не знаю.

Цитата

Цитата D_KEY @ 14.03.11, 19:57

Еще раз прошу пояснить мне, в чем тогда принципиальная концептуальная разница между интерфейсом и абстрактным классом?

Опять по кругу? N страниц назад уже пояснялось и приводились задачи, где вам чтобы добиться схожего поведения, приходилось городить огороды костылей.

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

Цитата

Это отчасти вытекает из идеологии COM'а

Причем тут какая-то технология?
Это все "физика".

Цитата

интерфейс - это абстрактный протокол, который описывает только взаимодействие с объектом и не содержит детали его реализации.

Совершенно верно.

Цитата

Теперь возьмём интерфейс Y, описывающий некоторый абстрактный протокол, этот интерфейс могут реализовывать несколько классов YA, YB, YC, в этом случае они "наследуют" и реализовывают протокол взаимодействия и т.к. никакой базовой реализации у интерфейса нет - YA, YB, YC реализовывают протокол взаимодействия полностью сами, при этом теперь никем не гарантируется, что будет работать принцип подстановки Лисков

Это уже идиотизм. Зачем передавать сущность, в качестве реализующей контракт, если она его не реализует?

Цитата

Тоже самое касается и наследования интерфейсов, должен соблюдаться не только сигнатурный контракт, но и гарантированно семантический, а для этого класс A, должен содержать реализацию интерфейсов и child и parent.

Когда child говорит, что он расширяет parent, он тем самым говорит, что он обеспечивает и parent. Неужели нет? Тогда что он говорит и зачем?

Цитата D_KEY @ 15.03.11, 06:55

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

Извини, но вы в очередной раз увиливаете

Цитата D_KEY @ 15.03.11, 06:55

Причем тут какая-то технология?

Почитай "Сущность технологии СОМ" (Дональд Бокс), там подробно рассматриваются данные аспекты и мотивы их решений.