Здравствуйте, Mr. None, Вы писали:

MN> За окном шёл снег и рота краснармейцев. */

Придется давать методам длинные осмысленные имена обозначающие что-то очень конкретное. Тогда вероятность совпадения сигнатур двух методов выполняющих разные по смыслу действия будет минимальна.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Mr. None, Вы писали:

MN>> За окном шёл снег и рота краснармейцев. */

SYG>Придется давать методам длинные осмысленные имена обозначающие что-то очень конкретное. Тогда вероятность совпадения сигнатур двух методов выполняющих разные по смыслу действия будет минимальна.

Нет. Совпадение сигнатур ещё не означает, что объекты состоят в отношении потомок-предок и подобное преобразование ошибочно! Кстати, даже отношение тип-подтип, которое достигается статическим наследованием (см. выше), не всегда является отношением предок-потомок, но это так — размышления.

Здравствуйте, Sinclair, Вы писали:

S>А можно пару комментариев, почему?

Возьмем множество всех множеств которые не включают себя как свой элемент. И зададим вопрос Включает ли это множество само себя? Исходя их определения если оно себя включает, то оно себя не включает и наоборот.

http://www.yandex.ru/yandsearch?rpt=rad&text=%EF%E0%F0%E0%E4%EE%EA%F1%FB+%F2%E5%EE%F0%E8%E8+%EC%ED%EE%E6%E5%F1%F2%E2

Здравствуйте, Mr. None, Вы писали:

MN>Нет. Совпадение сигнатур ещё не означает, что объекты состоят в отношении потомок-предок и подобное преобразование ошибочно! Кстати, даже отношение тип-подтип, которое достигается статическим наследованием (см. выше), не всегда является отношением предок-потомок, но это так — размышления.

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

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Mr. None, Вы писали:

MN>>Нет. Совпадение сигнатур ещё не означает, что объекты состоят в отношении потомок-предок и подобное преобразование ошибочно! Кстати, даже отношение тип-подтип, которое достигается статическим наследованием (см. выше), не всегда является отношением предок-потомок, но это так — размышления.

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

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

Могу привести другой пример бездумного использования наследования:
класс очереди оконных сообщений, унаследованный публичным образом от класса список на том лишь основании, что очередь сообщений использует функционал списка. В этом случае тоже возможны подобные преобразования: объект очередь оконных сообщений в объект список — это же bred of sive ckable!

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Возьмем множество всех множеств которые не включают себя как свой элемент.
Этот парадокс построен исключительно на возможности определять множество декларативно. Он показывает не слабость теории множеств, а ограниченность декларативных определений. Вообще, декларативные определения подобного рода встречаются сплошь и рядом. Они обходятся путем наложения ограничений на предикаты, служащие генераторами. Например, подобный же парадокс возможен при выполнении запроса в SQL-99. К счастью, существует простой алгоритм проверки, содержит ли подобное противоречие SQL-запрос.

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

Здравствуйте, Mr. None, Вы писали:

MN>И что? Следовательно разрешать преобразовывать объект "снег" к объекту "рота красноармейцев" только на том основании, что и то и другое может идти? И при этом совершенно не важно, что эти объекты ну никак не являются родственными? Так что ли?

Нет, преобразовывать объект в объект нельзя. Но можно преобразовывать вот так:

interface F {
  void f();
}

class A {
  f, g
}

class B {
  f, h
}

void f(F f) {
  f->f();
}

void main() {
  A a;
  B b;
  f((F)A); f((F)B);
}

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

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Mr. None, Вы писали:

MN>>И что? Следовательно разрешать преобразовывать объект "снег" к объекту "рота красноармейцев" только на том основании, что и то и другое может идти? И при этом совершенно не важно, что эти объекты ну никак не являются родственными? Так что ли?

Q>Нет, преобразовывать объект в объект нельзя. Но можно преобразовывать вот так:
Q><...>
Q>Т.е. иметь возможность преобразовывать объекты к интерфейсам, от которых они не наследовались и чтобы возможность такого приведения определялась только наличием у объекта нужных функций. Обратное преобразование, естественно, разрешать нельзя.

Ага, возвращаясь к нашим ёжикам и красноармейцам, имеем:

interface IБоеваяЕдиница
{
 public:
    void Идёт();
};

void ИзменитьДислокацию(IБоеваяЕдиница obj)
{
    obj.Идёт();
}

Снег снег;
ИзменитьДислокацию((IБоеваяЕдиница)снег); // Н-да... вы уверены, что именно это имели в виду?

Здравствуйте, Mr. None, Вы писали:

MN>Ага, возвращаясь к нашим ёжикам и красноармейцам, имеем:

MN>

MN>interface IБоеваяЕдиница
MN>{
MN> public:
MN>    void Идёт();
MN>};

MN>void ИзменитьДислокацию(IБоеваяЕдиница obj)
MN>{
MN>    obj.Идёт();
MN>}

MN>Снег снег;
MN>ИзменитьДислокацию((IБоеваяЕдиница)снег); // Н-да... вы уверены, что именно это имели в виду?
MN>

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

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>>Есть один очень важный момент, про который часто забывают. Если у нас объект унаследован от нескольких интерфейсов, то просто поглядев на список наследования уже можно понять, где этот объект может быть применён и отчасти — чем он является.

SYG>1) Объект не наследует интерфейсы, а реализовывает их.

Да, ты прав. Наследование — это только метод.

SYG>2) А чем являются и каков способ применения следующих объектов: "палка из дерева", "кусок камня", "комок ваты", "капля чернил", "калькулятор, довольно прочный на вид, так что им можно гвозди забивать" и т.д?

На этот вопрос невозможно ответить, не задав дополнительного: "А в каком контексте?"

SYG>Я же привел формулу g(N) = 2^N — 2 для количества разных вариантов использования одного и того же объекта, из которой видно, что это самое количество вариантов растет экспоненциально. Следовательно, если разработчик класса объекта будет явно прописывать возможные варианты использования этих объектов, то он сможет написать лишь ничтожно малую часть вариантов (устанет писать).

В ожеговском словаре русского языка 56 г. издания около 56000 слов. И поверь, далеко не все тексты, сотавленные из этих слов имеют хоть какой-то смысл. Какой смысл у комбинации "к, в, на"? Подсказка: психоделические мотивы не привлекать.

Здравствуйте, S.Yu.Gubanov, Вы писали:

MN>> За окном шёл снег и рота краснармейцев. */

SYG>Придется давать методам длинные осмысленные имена обозначающие что-то очень конкретное. Тогда вероятность совпадения сигнатур двух методов выполняющих разные по смыслу действия будет минимальна.

Угу, уже тепло.

Здравствуйте, S.Yu.Gubanov, Вы писали:

На самом деле идея весьма здравая. Такой подход позволит полностью выкинуть интерфейсы из списка наследования классов, что ИМХО есть очень хорошо. В конце концов что такое интерфейс? — место где встречаются и взаимодействуют независимые системы. В идеале м-ду обьектом и интерфейсом должны осуществлятся отношения "использования", т.е. интерфейс использует обьект. Когда обьект реализует интерфейс или наследуется от него то это уже костыли и грабли. Почему грабли и костыли? Потому что списочек фиксирован:

class Foo : public IFoo, public IBar

И свободных мест нет (особенно в thrid party классах );

Уважаемый S.Yu.Gubanov фактически предложил полностью отделить интенрфейс от реализации, т.е. сделать связь интерфейс-обьект очень слабой (наследование это очень сильная связь). Так и должно быть в иделае.

Примечательно что у себя в проекте мне недавно приходилось делать нечто подобное, правда ручками все. Т.е. примерно вот так:

    // some Node class
    class Node {
    public:
        void    get( int &value, const char *key );
        void    set( int value, const char *key );
        // ... etc
    };

    // VTFable for INode
    struct INodeVFT {
        bool (*int_get)(void *node, int *v, const char *key, ErrorInfo *e);
        bool (*int_set)(void *node, int v, const char *key, ErrorInfo *e);
        // ... etc
    };

    // отделенный обертывающий интерфейс
    struct INode {
        void            *node; // некий узел не обязательно Node
        const INodeVFT    *vft;  // самодельная в-тейбл.

    public:
        int int_get( const char *key ) // функция хелпер для удобства
        {
            int i;
            ErrorInfo e;
            if ( (vft->int_get)( node, &i, key, &e ) )
                return i;
            throw Error(e);
        }
    };

    // поскольку нет наследования то "оператор" приведения типа прилагается
    void wrap( Node *n, INode &node )
    {
        node.node = n;
        node.vft  = &NodeVFT;
    }

    // a это оборачиватель для ThirdParty Node
    void wrap( ThirdPartyNode *n, INode &node )
    {
        node.node = n;
        node.vft  = &ThirdPartyNodeVFT;
    }

// ==================================================================
// юзалось это так:
// ==================================================================

    void acceptMyNode( Node *n )
    {
        INode node;
        wrap( n, node );
        doNodeWork( node );
    }

    void acceptThirdPartyNode( ThirdPartyNode *n )
    {
        INode node;
        wrap( n, node );
        doNodeWork( node );
    }

    void doNodeWork( INode node )
    {
        int x = node.int_get("FooBar");
    }

Здравствуйте, Quintanar, Вы писали:

Q>Здравствуйте, Mr. None, Вы писали:

Q>Здесь налицо неправильный подход к определению функции. Поскольку она не делает ничего боеваяединицаспеципичного, то нефиг в нее передавать такой интерфейс.

Что значит неправильный подход к определению функции? А какой правильный? У меня есть интерфейс, который что-то определяет, мне нужна функция, которая будет каким-то образом использовать функционал объектов, предоставляемый через этот интерфейс. Что более надо? И тем более, что данный пример как раз более чем боеваяединицаспеципичный: функция, изменяющая дислокацию боевой единицы, она использует единственный метод интерфейса — идти.

Q>И сам интерфейс к боевым единицам отношения не имеет, он определяет только нечто, что ходит.

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

interface IWavPlayer // Интерфейс проигрывателя wav-файлов
{
 public:
    void Play();
};
class MainGameObject // Основной объект игры
{
 public:
    void Play();
};

PlayMusic(IWavPlayer player) // некий метод, который проигрывает музыку в фоне.
{
    // запуск нового потока
    player.Play();
}
MainGameObject game;
PlayMusic((IWavPlayer)game); // И?!!

Q>Ты сам написал, что можно намудить с обычным наследованием, так и здесь можно намудить при желании какую-нибудь чушь.

Не намудрить, а неправильно использовать понятия: использовать отношение тип-подтип там, где нужно потомок-предок. Статическое наследование используется и для одного и для другого — оно имеет право жить, главное правильно его использовать. К сожалению эти правила носят чисто деклоративную семантику и их нельзя закрепить в коде — это факт. Но если система спроектирована правильно и все эти правила соблюдены, то вам не удасться нарушить правила типизации компилятора и преобразовать объект "снег" к объекту "рота красноармейцев", даже если они имеют идентичный список методов. Для того типы и были введены — дабы избежать некорректного использования объектов в выражении. И для того было введено наследование, чтобы разрешить группам разных объектов, но со схожими свойствами использоваться в одних и тех же выражениях. Так зачем же добавлять механизм, который нарушает все эти старания?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Всвязи с этим, возникает вопрос: А не стоит ли для интерфейсов ввести такое понятие как ВКЛЮЧЕНИЕ ИНТЕРФЕЙСОВ и, соответственно, отказаться от наследования интерфейсов, поскольку включение — есть более мощный механизм нежели механизм наследования?

SYG>Практически, это будет выражено в том, что когда разработчик будет писать код класса, то ему не надо будет явно перечислять все интерфейсы поддерживаемые объектами этого класса. Вместо этого, когда у объекта этого класса будет запрошена услуга по какому-либо интерфейсу, то среда исполнения сама создаст соответствующую этому интерфейсу интерфейсную переменную ссылающуюся на соответствующие процедуры этого объекта (если это возможно; если невозможно, значит не создаст). Таким образом, механизм включения интерфейсов позволит писать меньше кода и создавать более гибкие программы.

Все крайне просто. Если рассматривать только наследование интерфейсов (без наследования реализации), то по выразительной силе это совершенно эквивалентно динамической диспетчеризации вызова. В самом деле:
Запихнем каждую функцию в свой интерфейс. Перед вызовом функции запрашиваем у объекта соотв. интерфейс. Что получается? Динамическая типизация. Начинаем группировать несколько функций в один интерфейс. Суть остается та же, но количество проверок типов уменьшается. Эта техника в сочетании с "наследованием" (расширением) интерфейсов позволяет внести динамическую семантику вызовов в строго типизированный язык.

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

Здравствуйте, Kluev, Вы писали:

K>Здравствуйте, S.Yu.Gubanov, Вы писали:

K>На самом деле идея весьма здравая. Такой подход позволит полностью выкинуть интерфейсы из списка наследования классов, что ИМХО есть очень хорошо. В конце концов что такое интерфейс? — место где встречаются и взаимодействуют независимые системы.

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

K>В идеале м-ду обьектом и интерфейсом должны осуществлятся отношения "использования", т.е. интерфейс использует обьект.

А вот это, извините, полная чушь. Как контракт может использовать своего владельца ("И мы имеем наших женщин, которые имеют наши магазины, которые имеют нас как хотят" (C) Жванецкий). Интерфейс всегда (подчёркиваю — всегда) реализуется объектом. Он может быть декларативным, динамически формируемым, статически типизированым, но реализуется он всегда объектом, а не использует свой объект.

K>Когда обьект реализует интерфейс или наследуется от него то это уже костыли и грабли. Почему грабли и костыли? Потому что списочек фиксирован:
K>

K>class Foo : public IFoo, public IBar
K>

K>И свободных мест нет (особенно в thrid party классах );

K>Уважаемый S.Yu.Gubanov фактически предложил полностью отделить интенрфейс от реализации, т.е. сделать связь интерфейс-обьект очень слабой (наследование это очень сильная связь). Так и должно быть в иделае.

Связь между объектом и интерфейсом не может быть слабой. Она есть, и она сильна — и всё тут. Связь между объектом и его типами может быть слабой — это уже языки с динамической типизацией (SmallTalk). То есть вы посылаете любое сообщение объекту и он его либо обрабатывает, если сообщение соотноситься с его интерфейсом, либо нет. Но при этом список обрабатываемых объектом сообщений всегда постоянен — это и есть интерфейс данного объекта. А, простите, что это за херомантия получается, если связь между объектом и интерфейсом слабая, сегодня объект обрабатывает данное сообщение, а завтра нет... Это только в российской действительности ответственная сторона может менять соглашение по своему усмотрению, извинте за лирическое отступление.

Здравствуйте, Mr. None, Вы писали:

MN>К сожалению эти правила носят чисто деклоративную семантику и их нельзя закрепить в коде — это факт.

Но может быть все-таки можно как-нибудь обмозговать это дело и решить проблему?...

MN> Так зачем же добавлять механизм, который нарушает все эти старания?

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

Здравствуйте, Mr. None, Вы писали:

K>>В идеале м-ду обьектом и интерфейсом должны осуществлятся отношения "использования", т.е. интерфейс использует обьект.

MN>А вот это, извините, полная чушь. Как контракт может использовать своего владельца ("И мы имеем наших женщин, которые имеют наши магазины, которые имеют нас как хотят" (C) Жванецкий).
Когда мы спустимся с академических высот на низкий уровень реализации то это имеет место быть. Посмотрите кодец котороый я привел. Класс который выполняет функцию интерфейса исползьует класс реализацию. Т.е. обьект "интерфейс" используеет обьект "обьект"

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

Я имел ввиду уже физический уровень реализации, ну не буду же я все время писать "обьект интерфейсного класса"? такое и читать то будет невозможно. Смотрите в подтекст и все будет ясно и непротиворечиво.

Здравствуйте, S.Yu.Gubanov, Вы писали:

L>>Читал и смеялся. Давайте обозначим 1=двигатель, 2=сиденья, 3=мотор... Дальше продолжать?

SYG>Попытайтесь понять смысл выражения "1=двигатель, 2=сиденья, 3=мотор", тогда посмеетесь еще больше.

а что не так со смыслом? С "3=мотор" был не прав. Пусть будет "3=бензобак" Итого, ввели алиас для 1, алиас для 2, алиас для 3... В чем проблема? Получим что "машина" = {1,2,3,4} = {двигатерль, сиденья, бензобак, колеса} .

Здравствуйте, Larm, Вы писали:

L>а что не так со смыслом? С "3=мотор" был не прав. Пусть будет "3=бензобак"

"3" — это число, то есть абстракция. "бензобак" — эта такая фиговина куда бензин наливают. Спрашивается, как понимать выражение "3=бензобак"?

Здравствуйте, Kluev, Вы писали:

K>Когда мы спустимся с академических высот на низкий уровень реализации то это имеет место быть.

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

K>Посмотрите кодец котороый я привел. Класс который выполняет функцию интерфейса исползьует класс реализацию. Т.е. обьект "интерфейс" используеет обьект "обьект"

Насколько я смог понят, вы привели ручную реализацию динамической типизации. И то, что вы называете объектом "интерфейс" интерфейсом как таковым не является. Интерфейс — это как раз список сигнатур функций, реализуемых тем или иным объектом Node. Если объект сохранённый в переменной *node не реализует функции get и set (не поддерживает определённый интерфейс), то ничего у вас не склеиться.

MN>>Интерфейс всегда (подчёркиваю — всегда) реализуется объектом. Он может быть декларативным, динамически формируемым, статически типизированым, но реализуется он всегда объектом, а не использует свой объект.

K>Я имел ввиду уже физический уровень реализации, ну не буду же я все время писать "обьект интерфейсного класса"? такое и читать то будет невозможно. Смотрите в подтекст и все будет ясно и непротиворечиво.

На физическом уровне реализации вообще никаких интерфейсов нет см. выше про биты и байты. А такого понятия как "объект интерфейсного класса" вообще не существует. Есть понятие объекта определённого класса, реализующего определённый интерфей. У интерфейса вообще не может быть объекта, потому как это декларация и она не может быть инстанцирована.