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

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

Вы показали не концептуальные различия, вы показали конкретную фичу, конкретного яп

Нет. Так ведут себя все языки, где есть интерфейсы.

Цитата

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

Все зависит от того, что вы понимаете под интерфейсами
Мне кажется, что вы не очень понимаете текущий контекст данного обсуждения

Цитата

Всякие же плюшки, приведеные вами ранее, никак не связаны с концепцией интерфейсов.

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

Добавлено 01.11.11, 13:57

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

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

В вашем ее понимании

Добавлено 01.11.11, 13:57

Цитата Romkin @ 01.11.11, 13:52

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

Вообще-то это уже роль абстрактного класса

Цитата Romkin @ 01.11.11, 13:52

Вот, от MS: Recommendations for Abstract Classes vs. Interfaces

Понимаешь, в чем соль, в шарпе все что там написано, возлагается либо на абстрактные классы, либо на интерфейсы. В С++ весь этот блок относится к абстрактным классам. Т.е. смесь этого всего в одну сущность.

Добавлено 01.11.11, 14:03

Цитата D_KEY @ 01.11.11, 13:56

Нет. Так ведут себя все языки, где есть интерфейсы.

Конкретно какие и как именно себя ведут? ты имеешь ввиду пример флекса?

Цитата D_KEY @ 01.11.11, 13:56

Все зависит от того, что вы понимаете под интерфейсами

Некую сущность, которая предоставляет пользователю некую абстракцию, которая реализуется множеством классов, и может иметь разные реализации. Что то типо того.

Цитата D_KEY @ 01.11.11, 13:56

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

Вот именно что в терминологии тех языков, а не в концепции в целом.

Цитата D_KEY @ 01.11.11, 13:56

В вашем ее понимании

А в вашем, нет?

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

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

Некую сущность, которая предоставляет пользователю некую абстракцию, которая реализуется множеством классов, и может иметь разные реализации. Что то типо того.

Тогда да, абстрактные классы подходят. Именно поэтому я и говорю о том, что в языках с множественным наследованием интерфейсы не нужны

Цитата korvin @ 01.11.11, 13:33

в общем-то не обязательно, считайте имя пакета частью имени метода

Цитата MyNameIsIgor @ 01.11.11, 13:29

Иначе она вообще на хэ не нужна.

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

Цитата Romkin @ 01.11.11, 13:46

Видит. И как правило видит он объявление класса. Где гарантия, что подразумевался именно этот интерфейс?

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

Добавлено 01.11.11, 14:34

Цитата MyNameIsIgor @ 01.11.11, 14:08

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

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

Добавлено 01.11.11, 14:39

Цитата Romkin @ 01.11.11, 13:52

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

это указывается в имени интерфейса/пакета и документации к нему, при чем тут явное декларирование реализации интерфейса классом?

Цитата korvin @ 01.11.11, 14:30

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

При чём тут вообще это? Почему интерфейс и пакет через дробь? Это взаимозаменяемые понятия что ли?
Я говорил про утиную типизацию применительно к интерфейсам как говорил D_KEY. И я не вижу в ней смысл в рамках одного модуля, потому что в нём как раз можно и явно декларировать реализацию. Она могла бы пригодиться как раз в том случае, если мы получили модуль, который не можем изменить, и используем из него класс как реализующий интерфейс из совсем другого модуля.
Но опять же это выглядит нехорошо, да и можно как говорил Romkin сделать наследника.

Цитата korvin @ 01.11.11, 14:30

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

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

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

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

Цитата korvin @ 01.11.11, 15:43

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

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

Сообщение отредактировано: MyNameIsIgor - 01.11.11, 16:20

Цитата Flex Ferrum @ 01.11.11, 06:39

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

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

Цитата D_KEY @ 01.11.11, 06:36

Однако написал ты нечто совершенно другое

Это тебя с Romkin-ым понесло в нечто другое, а именно - интерфейсы, мол, нет множественного наследования реализаций. Когда обсуждали множественное наследование, ты сам приставал к дельфистам с вопросом "ну а что если вдруг нужны две разные реализации одного интерфейса", как и я привёл пример с разными сокетами (правда реализация тут одна, но всё равно два объекта) на что тебе (или мне, или это другой вопрос был) было продемонстрирована агрегация с делегацией. Поскольку при необходимости агрегация может накостылить множественность наследования (ты ж тогда ещё добил "зачем тогда наследование вообще, если агрегация с тем же успехом может заменить и простое наследлование"), я и спросил то, что спросил. Об интерфейсах не я заикнулся, и мне непонятно, зачем вы холиварите, если спустя чуток времени уже ничего не помните.

Цитата D_KEY @ 01.11.11, 06:36

Странные и ни чем не подкрепленные выводы

Зачем мне это делать, если достаточно вас почитать.

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

Цитата Flex Ferrum @ 01.11.11, 08:25

Тогда перепиши на C++ пример из этого поста: Delphi vs C++ vs C# (сообщение #3016643) , только без введения новых линий наследования.

Ты не прав в постановке задачи. Одноимённость перекрытых методов не означает реализацию интерфейса.

interface IStack
{
  push();
  pop();
  getTop();
  isEmtry();
}
 
class MDIWindowContainer
{
  push();
  pop();
  get();
  isEmtry();
}

Не D_KEY ли korvin-у доказывал, что совпедание сигнатур методов ни о чём не говорит?

Цитата MyNameIsIgor @ 01.11.11, 16:12

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

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

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

package x;
 
class A implements y.I, y.J {
  // ...
}

package z;
 
import x.A;
 
interface K {
  // ...
}
 
implement K for A {
  // ...
}

почему в джавошарпе такого не сделали -- не знаю, вот в CLOS, Go и Haskell сделали.

Цитата Qraizer @ 01.11.11, 16:12

Не D_KEY ли korvin-у доказывал, что совпедание сигнатур методов ни о чём не говорит?

Не, это я делал с большой пеной у рта. Когда доказывал D_KEY'ю, что утиная типизация для интерфейсов - плохо

Цитата Romkin @ 01.11.11, 11:58

Зато нет вопросов что белать с ромбом в наследовании

Меня походу вообще не читают. Ромб в наследовании - это не проблема программиста. Задачей архитектора является указать, что делать с одинаковыми аттрибутами и как делать. Задача. Он знает, нужно ли совмещение или разделение. И лично я большей частью в C++ использую разделение, т.к. гораздо чаще востребовано дизайном. Не существует проблемы ромба в множественном наследовании реализаций, существует проблема реализации архитектуры, выданной архитектором системы, средствами выбранного языка програмирования.

Добавлено 01.11.11, 16:39

Цитата D_KEY @ 01.11.11, 12:00

А, ну я что-то вроде этого предлагал в нашей серии тем, за что был закидан камнями

Не, ты был закидан не за это. Тебя не так поняли и решили, мол, это так и надо. Это один из вариантов - вон, Flex Ferrum-а тоже на неё тянет - почему бы и нет. Но - гораздо менее надёжный, нежели предвартельное предоставление контракта, ибо чревато случаностями, недетектируемыми или непонятно детектируемыми на ранних стадиях. Когда нет другого варианта - насколько я помню, шёл разговор о статическом полиморфизме - это вполне вариант.

Цитата Qraizer @ 01.11.11, 16:12

Цитата D_KEY @ 01.11.11, 06:36

Странные и ни чем не подкрепленные выводы

Зачем мне это делать, если достаточно вас почитать.

Т.е. я "апологет других языков"? Вообще-то, мне больше нравится множественное наследование + абстрактные классы, чем подход Java/Delphi/C#. Я просто пояснял концепцию интерфейсов.

Цитата

Ты не прав в постановке задачи. Одноимённость перекрытых методов не означает реализацию интерфейса.

interface IStack
{
  push();
  pop();
  getTop();
  isEmtry();
}
 
class MDIWindowContainer
{
  push();
  pop();
  get();
  isEmtry();
}

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

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

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

Добавлено 01.11.11, 16:55

Цитата Qraizer @ 01.11.11, 16:34

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

И как же живут бедные люди, пишущие системы на языках с динамической типизацией ?!

Цитата Qraizer @ 01.11.11, 16:34

Меня походу вообще не читают. Ромб в наследовании - это не проблема программиста. Задачей архитектора является указать, что делать с одинаковыми аттрибутами и как делать. Задача. Он знает, нужно ли совмещение или разделение. И лично я большей частью в C++ использую разделение, т.к. гораздо чаще востребовано дизайном. Не существует проблемы ромба в множественном наследовании реализаций, существует проблема реализации архитектуры, выданной архитектором системы, средствами выбранного языка програмирования.

У интерфейса нет атрибутов, там только методы. ТАк или иначе. Не ты ли меня допрашивал насчет ромба?

Добавлено 01.11.11, 16:57

Цитата Qraizer @ 01.11.11, 16:12

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

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