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

NBN>>>>Абстрактный класс — это класс объект которого не может быть создан.
S>>>Я с ЦПП дано не работал, поэтому вопрос: Из вашего определения получается что простой класс с одним конструктором который бросает исключение -- это абстрактный класс? Ведь если вывалится исключение, то экземпляр не будет создан? Или будет?
NBN>>Хорошее замечание. Добавим пункт: на этапе компиляции.

D>И опять неверно. В Дельфи, например, можно создать экземпляр абстрактного класса.
Причёт тут дельфи?

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

о_О>Воскресный вброс на хабрэ. Ничего сверх, исключительно для ознакомления

Юзергрупп какой-то... Нафиг надо. Теннисный стол лучше.

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

S>>В контексте реализации на ЦПП, интерфейс отличается тем что не может содержать деталей реализации (типа полей и реализованных методов). И фактически является скорее шаблоном проектирования.

NBN>Нет, точнее это типичный мутант, бессмысленное совмещение понятий из разных областей.

NBN>Абстрактный класс — это класс объект которого не может быть создан.
NBN>Интерфейс (класса) — это его объявление.

Вот — посиди, подумай:

// Интерфейс
class Openable
{
public:
    virtual void Open() = 0;
    virtual bool IsOpen() const = 0;
};

// Абстрактный класс
class AbstractPort
    : public Openable
{
public:
    void Open()
    {
        ...
        DoOpen();
        ...
    }

    bool IsOpen() const
    {
        return IsOpen_;
    }

protected:
    Descriptor Port_;

private:
    virtual void DoOpen() = 0;

    bool IsOpen_;
};

// Конкретный класс
class Can
    : public Openable
{
public:
    Can()
        : IsOpen_(false)
    {
    }

    void Open()
    {
        IsOpen_ = true;
    }

    bool IsOpen() const
    {
        return IsOpen_;
    }

private:
    bool IsOpen_;
};

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

S>>>Я с ЦПП дано не работал, поэтому вопрос: Из вашего определения получается что простой класс с одним конструктором который бросает исключение -- это абстрактный класс? Ведь если вывалится исключение, то экземпляр не будет создан? Или будет?
NBN>>Хорошее замечание. Добавим пункт: на этапе компиляции.
S>О, так это не определение, а ваше творчество? А если найти в компиляторе то место которое проверяет создание классов и "подфиксить"?
Есть много способов выстрелить себе в ногу. Например можно легко создавать объекты класса с приватными конструкторами:
Test t = t;

S>Вам не кажется что
S>

S>Абстрактный класс -- это частично-реализованный класс

S>Если оно не корректно, то укажите где.
Нормальное определение, немного с другой стороны.

NBN>>>>Интерфейс (класса) — это его объявление.
S>>>А какой смысл сравнивать "Абстрактный класс" и то что вы назвали "Интерфейс класса" (Я помню термин "Объявление класса")?
NBN>>Никакого, это ортогональные понятия. О том и речь.
S>Почему ортогональные. Скорее параллельные, даже в контексте конкретного языка. Вот только тут другой вопрос: Насколько человек мыслит в ООП, а на сколько в терминах языка? И насколько это хорошо?
На разных уровнях по разному, чем выше — тем более обще, но тем не менее язык и парадигма всё-таки оказывают серьёзно влияние.

NBN>>Не вижу логики, если честно. Протокол, контракт, интерфейс — это то через что автор класса предлагает работать клиенту.
NBN>>Абстрактный класс — это деталь реализации.
S>А если посмотреть так: Абстрактный класс -- это частично реализованный протокол.
Протокол не может быть частично реализованным.

S>Абстрактный класс, как и любой другой класс может сам объявлять протокол.
Деталь реализации. Пользователю это безразлично.

NBN>>я над тем и посмеялся.
S>Вы очень забавно посмеялись, продемонстрировав что вы более привязаны к конкретной реализации концепции чем в общем к подходу.
Мы говорили именно о С++. Не о программировании вообще, не об архитектуре и не о шаблонах.

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

S>Если же вернуться к первоначальной статье, то разница "абстрактный класс/интерфейс" -- это синоним "знание теории" (пусть ответ и будет, в некотором плане, зависеть от сферы деятельность/языка). Понимание этого, кстати, демонстрирует возможность человека к созданию абстракций.
Тем не менее эти понятия определяются совершенно однозначно в C# и Java и не совсем однозначно и совершенно по другому в С++, где класс с приватными конструкторами может быть абстрактным.

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

NBN>>Абстрактный класс — это класс объект которого не может быть создан.
NBN>>Интерфейс (класса) — это его объявление.

MTD>Вот — посиди, подумай:

Над чем?

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

D>>И опять неверно. В Дельфи, например, можно создать экземпляр абстрактного класса.
NBN>Причёт тут дельфи?

Как пример, опровергающий твое определение. Я про общее понятие абстрактного класса без учета конкретного языка, если что.

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

D>>>И опять неверно. В Дельфи, например, можно создать экземпляр абстрактного класса.
NBN>>Причёт тут дельфи?

D>Как пример, опровергающий твое определение. Я про общее понятие абстрактного класса без учета конкретного языка, если что.

Мы говорим про С++.

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

MTD>>Вот — посиди, подумай:

NBN>Над чем?

Ну раз тебе не над чем

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

MTD>>>Вот — посиди, подумай:

NBN>>Над чем?

MTD>Ну раз тебе не над чем

Я так понял, что ты намекал на свой комментарий?

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

S>О, так это не определение, а ваше творчество?

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

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

NBN>Я так понял, что ты намекал на свой комментарий?

Я показал на конкретном примере отличия абстрактного класса и интерфейса. Хотя конечно, разделение этих понятий в компетенции программиста и языком не описываются (С++).

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

NBN>>Я так понял, что ты намекал на свой комментарий?

MTD>Я показал на конкретном примере отличия абстрактного класса и интерфейса. Хотя конечно, разделение этих понятий в компетенции программиста и языком не описываются (С++).

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

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

NBN>Твой AbstractPort является точно таким же интерфейсом, как и твой Openable. И то и другое — абстрактные классы и предоставляют интерфейсы, Can — предоставляет интерфейс и это не абстрактный класс.

Как все запущено

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

NBN>>Твой AbstractPort является точно таким же интерфейсом, как и твой Openable. И то и другое — абстрактные классы и предоставляют интерфейсы, Can — предоставляет интерфейс и это не абстрактный класс.

MTD>Как все запущено

Кстати, меня в твой Акронис брали на должность кодеревьюера ещё до того как ты начал там работать

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

NBN>Кстати, меня в твой Акронис брали на должность кодеревьюера ещё до того как ты начал там работать

Ну раз по делу сказать больше нечего, то можно и пофлудить, но для начала несколько поправок:
1. Акронис не мой
2. Я там не работаю уже 3 года
3. Должности кодеревьюера когда я там работал не было — ревьюили все люди код которых затрагивал твой код

С точки зрения С++
1. Абстрактный класс(abstract class). В народе "чисто абстрактный класс", хотя в стандарте и нет такого определения. Содержит только виртуальные методы (pure virtual)
2. Абстрактный класс. Содержит один виртуальный метод.
3. Класс не содержащий чисто виртуальных методов (pure virtual). В народе "конкретный" класс.

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

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

TSP>1. Абстрактный класс(abstract class). В народе "чисто абстрактный класс", хотя в стандарте и нет такого определения. Содержит только виртуальные методы (pure virtual)
TSP>2. Абстрактный класс. Содержит один виртуальный метод.
Это какие-то очень странные условности

TSP>Первый класс стал "интерфейсом" только от того что в вашей архитектуре он является интерфейсом в общепринятом определении.
Интерфейс класса — это совокупность его публичных мемберов.

Тому кто продолжает настаивать на особой сущности interface в С++ нужно предложить дать определение виртуальному наследованию в рамках Java.

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

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

TSP>>1. Абстрактный класс(abstract class). В народе "чисто абстрактный класс", хотя в стандарте и нет такого определения. Содержит только виртуальные методы (pure virtual)
TSP>>2. Абстрактный класс. Содержит один виртуальный метод.
NBN>Это какие-то очень странные условности
С++ вообще штука странная, но писание гласит:

An abstract class is a class that can be used only as a base class of some other class; no objects of an
abstract class can be created except as sub-objects of a class derived from it. A class is abstract if it has at
least one pure virtual function. [Note: such a function might be inherited: see below. ]

Т.е. оба класса абстрактные.

Стих 10.4.1

An abstract class can also be
used to define an interface for which derived classes provide a variety of implementations.

Описание понятия интерфейса не приводится, т.к. выходит за рамки. Моё толкование такое. Абстрактный класс есть реализация концепции интерфейса в С++.



TSP>>Первый класс стал "интерфейсом" только от того что в вашей архитектуре он является интерфейсом в общепринятом определении.
NBN>Интерфейс класса — это совокупность его публичных мемберов.
"Интерфейс класса" это другое.

П>Да я в курсе. Но, по-моему, это крайне незначительная ерунда. Как там модно говорить, синтаксический сахар.
Эта ерунда очень значительная.

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

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

Какой проблемы с ромбовой иерархией ?