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

korvin, а просто подключение нужного предка в рантайме никак?

Цитата Romkin @ 01.11.11, 17:38

korvin, а просто подключение нужного предка в рантайме никак?

не понял тебя

korvin, тоже правильный вывод. Это не вопрос реализации, это вопрос дизайна.

Цитата Qraizer @ 01.11.11, 17:23

Впрочем, уже достаточно. Раз не ответил сразу, значит что? Точно - вопрос не имеет однозначного ответа. Ответ зависит от конкретики. Легко можно предстваить себе, что контейнеры журналов отличаются, так же легко - что они совпадают.
Главный вопрос: почему "проблема" ромба называется проблемой, если там точь в точь эта же ситуация? Дизайнер системы решает, как дожно быть, а программист это реализует. Всё, нет "проблемы". Как программист будет решать - наследованием, агрегацией - та пофиг.

Я наконец-то понял, о чем ты вообще
Согласен

Господа, а теперь для тупых...

Цитата MyNameIsIgor @ 01.11.11, 17:19

Меня смущает сам факт того, что автор класса не знает об интерфейсах, под видом которых класс будут использовать... Наверное, просто привык к языкам, где всё иначе.

дык а ему-то какая разница? он класс реализовал и все, а если кто-то хочет к нему еще какой интерфейс прикрутить -- пусть прикручивает, это уже его(прикручивальщика) заботы =) практически тоже самое что и реализация обертки/наследника, только удобнее =)

Цитата korvin @ 01.11.11, 17:42

практически тоже самое что и реализация обертки/наследника, только удобнее =)

Вот я на это так и смотрю. Как уже выше был озвучен взгляд на джавошарповские интерфейсы как на "просто удобнее абстрактных классов", так же и тут "просто удобнее обёртки". Я и говорил уже: да удобнее... но надо ли?

Цитата korvin @ 01.11.11, 17:40

не понял тебя

Я говорю, как насчет выбора реализации интерфейсов (в терминах абстрактных классов - предков) в рантайме, по месту?

Цитата MyNameIsIgor @ 01.11.11, 17:44

Вот я на это так и смотрю. Как уже выше был озвучен взгляд на джавошарповские интерфейсы как на "просто удобнее абстрактных классов", так же и тут "просто удобнее обёртки". Я и говорил уже: да удобнее... но надо ли?

ну не знаю, по-моему раз удобно, не сложно реализуется (+ есть примеры реализации), минусов никаких, то надо.

хотя минусов это _я_ не вижу, а по факту может и есть какие-то =/

Добавлено 01.11.11, 17:53

Цитата Romkin @ 01.11.11, 17:45

Цитата korvin @ 01.11.11, 17:40

не понял тебя

Я говорю, как насчет выбора реализации интерфейсов (в терминах абстрактных классов - предков) в рантайме, по месту?

нет, я решительно не понимаю, как это относится к вопросу Qraizer'а, ну выбрал ты два экземпляра одинаковых классов и что? тут опять же не факт, что они будут писать в один и тот же файл, может TA при инициализации генерирует (достаточно) уникальное имя файла, т.е. это уже чуть другая проблема конечно, но все же

Добавлено 01.11.11, 17:54
опять же, выбрал разные, а по условиям программа должна писать в _один_ лог-файл.

Сообщение отредактировано: korvin - 01.11.11, 17:54

Ну и собственно, почему я решил что "гвоздь". Потому что от начала и до сих пор Дельфи за программиста решает, что интерфейсы всегда совмещаются, реализации всегда разделяются. И если для интерфейсов у них ещё есть отмазка, мол, интерфейсы иначе не могут, ибо тогда они и не интерфейсы вовсе, а абстрактные классы (хотя по мне это не решение, а слив, из-за терминологической подоплёки отказаться решать практическую задачу - это моветон), то в случае реализаций и такого нет. В случае необходимости иметь различные реализации одного и того же интерфейса в одном компоненте приходится перепроектировать. Хотя наверняка это даже не замечается, а просто сразу на автомате делается по-другому, потому что простое плюсовое разделение в голову просто не приходит в связи с отсутствием поддержки в языке. В случае совмещения (возможно, частичной) реалиазций на агрегированные сущности навешивается инвариант и программируется руками. Тоже на автомате простое плюсовое совмещение ... в общем по той же причине.
Я просто думал, мож есть какие тайные фишки. Когда речь зашла о пропертях, я ж сразу вспомнил о всяких там контейнерах типа TPanel, подумал, может там аттрибуты координат как-то связываются на языковом уровне.

Цитата scorpion @ 01.11.11, 13:17

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

Для реализации общего функционала над группой интерфейсов или их реализаций (где они будут являться просто пассивными объектам), например универсальные фабрики/фреймворки.

korvin, TA и TB просто классы. Тот факт, что они что-то логгируют (наверно, всё-таки с друмя г ), используя один и тот же класс логгера (точно две ), ну, так получилось. Формально, с точки зрения TA и TB оба экземпляра логгера никак друг с другом не связаны. Если экземпляры TA и TB просто живут себе в программе и в ус не дуют, то разделение аттрибутов, связанных с реализацией ILog, естественно, но не обязательно. Если же экземпляры TA и TB живут в пределах одного класса как его составные кирпичики, неважно каким образом сложенные, хоть наследованием, хоть агрегацией, то наоброт совмещение аттрибутов естественно, но опять же не обязательно.

Цитата Qraizer @ 01.11.11, 17:54

Потому что от начала и до сих пор Дельфи за программиста решает, что интерфейсы всегда совмещаются, реализации всегда разделяются.

Это COM решил и большинстве случаев это именно так (надо).
Вот кстати:

//есть базовый
  IA = Interface
    procedure Foo;
  end;
 
//и пара производных
  IB = Interface(IA)
    //***//
  end;
 
  IC = Interface(IA)
    //***//
  end;
 
  TBC = class(TInterfacedObject, IB, IC)
  private
    //то что метод Foo из общего базового интерфейса,
    //считать это всё же коллизией?
  end;

Цитата Qraizer @ 01.11.11, 17:54

хотя по мне это не решение, а слив, из-за терминологической подоплёки отказаться решать практическую задачу - это моветон

Архитектор свою работу сделает

Цитата Qraizer @ 01.11.11, 17:54

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

?

Цитата Qraizer @ 01.11.11, 17:54

В случае совмещения (возможно, частичной) реалиазций на агрегированные сущности навешивается инвариант и программируется руками.

?

Цитата Qraizer @ 01.11.11, 17:54

Когда речь зашла о пропертях, я ж сразу вспомнил о всяких там контейнерах типа TPanel, подумал, может там аттрибуты координат как-то связываются на языковом уровне.

?

Добавлено 01.11.11, 19:41

Цитата Qraizer @ 01.11.11, 17:23

Дизайнер системы решает, как дожно быть

А если их больше одного?

Цитата DesweR @ 01.11.11, 18:02

Для реализации общего функционала над группой интерфейсов или их реализаций (где они будут являться просто пассивными объектам), например универсальные фабрики/фреймворки.

Похоже что ты запутался в своей формулировке. Наверное ты хотел сказать что то типо этого?

Цитата

"Для реализации неизвестного, общего функционала над группой неизвестных интерфейсов или их неизвестных реализаций, например неизвестные универсальные фабрики/фреймворки."

Я угадал?
DesweR, я на своей практике, как то не припомню задач, где бы мне потребовалось запрашивать интерфейс, неизвестный на этапе компиляции, у объекта, тоже неизвестного на этапе компиляции.... И главное зачем?
Единственный неизвестный интерфейс, который я знаю это интерфейс IUnknown, который служит для подсчета ссылок на объекты классов в COM технологиии... Но, этот интерфейс вполне известный, несмотря на его название

Добавлено 01.11.11, 21:01

Цитата D_KEY @ 01.11.11, 16:54

Я просто пояснял концепцию интерфейсов.

Исходя из

Цитата D_KEY @ 01.11.11, 16:54

подход Java/Delphi/C#

?

Добавлено 01.11.11, 21:05

Цитата D_KEY @ 01.11.11, 16:54

Т.е. ты видишь что-то плохое в коде:

      interface IStack
      {
        push();
        pop();
        getTop();
        isEmtry();
      }
      
      class MDIWindowContainer
      {
        push();
        pop();
        get();
        isEmtry();
      }
      
      class MyClass : MDIWindowContainer, IStack
      {
        // ...
      }

Интересно что? Ведь разработчик MyClass наверно знает, что делает, правда?

Хорошо, а если разработчик MyClass знает что делает, но, не догадывается, что в классе MDIWindowContainer уже реализован метод push, и реализовывает его в MyClass, что будет при использовании?

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

Цитата DesweR @ 01.11.11, 19:36

Это COM решил и большинстве случаев это именно так (надо).

Так я и не спорю. Но вот у мультиметодов Flex Ferrum-а как раз противоположная ситуация.

Цитата DesweR @ 01.11.11, 19:36

//то что метод Foo из общего базового интерфейса,
//считать это всё же коллизией?

Понятия не имею. Коли речь идёт об интерфейсах, наверное, нет. Но если придёт начальник и скажет, что заказчик передумал, и в TBC нужно разделить общий интерфейс IA так, чтобы IB и IC могли использовать разные реализации, то телодвижений для редизайна придётся сделать больше, нежели убрать virtual из базы. Зато заказчик будет будет сиять от радости, если в соответствии с его пожеланиями теперь один лог валится в виндовый журнал, а второй - в файл в %APPDATA%.
Конечно я утрирую. По-хорошему, чтоб счастливы были все и навсегда, тут нужен был бы паттерн... как там его... Стратегии. Т.е. каждый интерфейс реализуется отдельно, а TBC наследует реализации как кирпичики. Но я не буду и против, если дельфисты их агрегируют. Я б и сам, наверно, брал бы реализации не базовыми классами, а в виде указателей на их интерфейсы в параметрах конструктора. В системе такой архитектуры (привет, scorpion! понял, почему там было много базовых классов?) всё очень гибко, каждый кирпичик не зависит от соседних и может заменяться на другой аналогичный, не затрагивая соседей, а роль TBC сводится просто к инкапсуляции всех кирпичиков под одну крышу. Только этот паттерн плохо дружит с концепцией интерфейсов, ибо TBC обычно реализуют монолитом из всех его интерфейсов. А значит помимо "убрать/добавить virtual" TBC придётся ещё и редизайнить.

Цитата DesweR @ 01.11.11, 19:36

А если их больше одного?

Архитекторов? Это их проблемы. В конечном итоге разрабатывается одна система, и архитектура у неё, наилучшим образом подходящая под её предметную область, тоже единственная.
Ежели это не так, то тогда по большому счёту им пофиг, какое решение выбрать. И в этом случае они могут использовать иные методы отбора, например "почему бы не спросить программеров, как им удобнее".

Сообщение отредактировано: Qraizer - 01.11.11, 23:28