Определение интерфейсов (абстрактных классов без элементов) в C++

Вы задаете много вопросов, но я попробую.

Под интерфейсом (терминология C#) я подразумеваю абстрактный класс без элементов данных.

Ничего особенно похожего на интерфейс C# не существует. Наиболее близок абстрактный базовый класс C++, но есть и отличия (например, вам нужно будет определить тело для виртуального деструктора).

Таким образом, такой класс указывает только контракт (набор методов), который должны реализовать подклассы. Мой вопрос: как правильно реализовать такой класс в современном С++?

Как виртуальный базовый класс.

Пример:

class OutputSink
{
public:
    
    ~OutputSink() = 0;

    // contract:
    virtual void put(std::vector<std::byte> const& bytes) = 0;
};

OutputSink::~OutputSink() = default;

Следовательно, я предполагаю, что его следует объявить с помощью ключевого слова struct, поскольку в любом случае он содержит только общедоступные члены.

Существует несколько соглашений о том, когда использовать структуру, а когда класс. Я рекомендую руководство (эй, вы просили мнения: D) использовать структуры, когда у вас нет инвариантов их данных. Для базового класса используйте ключевое слово class.

«Полиморфный класс должен подавлять копирование»

В основном правда. Я написал код, в котором клиентский код не выполнял копии унаследованных классов, и код работал нормально (без их запрета). Базовые классы не запрещали это явно, но это был код, который я писал в своем хобби-проекте. При работе в команде рекомендуется специально ограничивать копирование.

Как правило, не утруждайте себя клонированием, пока не найдете реальный вариант его использования в своем коде. Затем реализуйте клонирование со следующей сигнатурой (пример для моего класса выше):

virtual std::unique_ptr<OutputSink> OutputSink::clone() = 0;

Если это по какой-то причине не работает, используйте другую подпись (например, верните shared_ptr). owner<T> — полезная абстракция, но ее следует использовать только в крайних случаях (когда у вас есть кодовая база, которая навязывает вам использование необработанных указателей).

Интерфейс должен состоять только из общедоступных методов. Он должен объявить [...]. Должно [...]. Он должен быть получен с использованием общедоступного виртуального.

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

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

class OutputSink
{
public:
     void put(const ObjWithHeaderAndData& o) // non-virtual
     {
          put(o.header());
          put(o.data());
     }

protected:
     virtual void put(ObjectHeader const& h) = 0; // specialize in implementations
     virtual void put(ObjectData const& d) = 0; // specialize in implementations
};

таким образом, абстрактный базовый класс всегда должен объявлять конструктор по умолчанию?! Я что-то неправильно понимаю?

При необходимости определите правило 5. Если код не компилируется из-за отсутствия конструктора по умолчанию, добавьте конструктор по умолчанию (используйте рекомендации только тогда, когда они имеют смысл).

Обновлено: (обращаясь к комментарию)

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

Не обязательно. Лучше (но на самом деле «лучше» зависит от того, с чем вы согласны с вашей командой) понимать значения по умолчанию, которые компилятор добавляет за вас, и добавлять код построения только тогда, когда он отличается от этого. Например, в современном C++ вы можете инициализировать элементы встроенными, часто полностью устраняя необходимость в конструкторе по умолчанию.

Хотя на большинство вопросов уже дан ответ, я решил поделиться некоторыми мыслями о конструкторе по умолчанию и виртуальном наследовании.

Класс всегда должен иметь общедоступный (или, по крайней мере, защищенный) конструктор, чтобы гарантировать, что подклассы все еще могут вызывать суперконструктор. Несмотря на то, что в базовом классе нечего конструировать, это необходимо для синтаксиса C++ и концептуально не имеет никакого значения.

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

Имеем следующую ситуацию:

struct A {
    int someData;

    A(): someData(0) {}
};

struct B : public A {
    virtual void modifyData() = 0;
};

struct C : public A {
    virtual void alsoModifyData() = 0;
};

struct D : public B, public C {
    virtual void modifyData() { someData += 10; }
    virtual void alsoModifyData() { someData -= 10; }
};

Когда modifyData и alsoModifyData вызываются для экземпляра D, они не будут изменять одну и ту же переменную, как можно было бы ожидать, из-за того, что компилятор создаст две копии someData для классов B и C.

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

Но интерфейсы могут строго наследоваться от других интерфейсов, исключая для начала проблему алмаза. В этом, конечно же, Java отличается от C++. Эти «интерфейсы» С++ по-прежнему могут наследоваться от классов, владеющих данными, тогда как в java это невозможно.

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

Я надеюсь, что этот ответ был (хотя и более концептуальным) полезным для вас!