Разработка интерфейса иерархии классов

[Aoizora]

Есть такой абстрактный класс:

class Abstract
{
protected:
    TypeA a;
    TypeB b;
    TypeC c;

public:
    virtual void  getA() = 0;
    virtual void getB() = 0;
    virtual void getC() = 0;

с набором полей и геттеров к этим полям. И несколько классов, производных от Abstract, которые инициализируются значениями из БД.

Интересует проектирование этой иерархии. Определять ли поля в общем абстрактном классе для наследования или дублировать и в каждом наследнике (лишний код)? Методы-геттеры должны быть чисто-виртуальными или просто виртуальные, реализованные в классе Abstract и наследуемые потомками, если в переопределении нет необходимости (например, логика в них онда и та же: возвращается значение поля)?

Могут быть две ситуации:
- Геттеры просто возвращают значение поля.
- Геттеры обращаются к базе, и тогда в класах-потомках логика может различаться

Какой подход лучше? Какой приведет со временем к меньшему объему работы, если понадобится рефакторить API?

[waleri]

У всех классов одинаковые поля?

Посмотрите как сделано в других ОРМ...

[Aoizora]

Сообщение от waleri

У всех классов одинаковые поля?

Посмотрите как сделано в других ОРМ...

А можете посоветовать конкретную ORM для C++?

[pu4koff]

Если добавите поля в абстрактный класс, то и геттеры нужно реализовывать. Если геттеры у наследников будут разные, то и полям нечего делать в абстрактном классе.
Или прописывать поля и геттеры, но заводить какие-нибудь protected void onGetA() для инициализации значения А и их уже перегружать в наследниках. а в геттере базового класса писать что-то типа:

if (a == NULL) onGetA();
return a;

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

[Aoizora]

Сообщение от pu4koff

Если добавите поля в абстрактный класс, то и геттеры нужно реализовывать. Если геттеры у наследников будут разные, то и полям нечего делать в абстрактном классе.
Или прописывать поля и геттеры, но заводить какие-нибудь protected void onGetA() для инициализации значения А и их уже перегружать в наследниках. а в геттере базового класса писать что-то типа:

if (a == NULL) onGetA();
return a;

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

Идея с перегрузкой onGetA() мне понравилась, потому что эти методы помогут поддерживать состояние класса актуальным после изменений в базе. А как учесть возможность загружать различные версии данных в этих методах? Допустим, даные за разные промежутки времени будут разными.

И еще вопрос: при разработке интерфейса какая разница будет между определением API виртуальными и чисто виртуальными?

[waleri]

Сообщение от Aoizora

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

При чисто виртуальных нет надобоности делать имплементацию метода интерфейса.

[Alex11223]

Сообщение от pu4koff

только это уже будет не интерфейс в его понимании ООП. Интерфейс не содержит никаких полей и хоть какой-либо реализации метода

То есть например Java и Kotlin не правильно понимают ООП?