Как придумать дополнительную таблицу виртуальных методов?

Question

[Mercury13]

У нас есть такой код. Сильно упрощаю, но всё-таки я про архитектуру, а не про компилируемость, верно?

enum class ObjType { GROUP, LEAF };

class Obj {
public:
  virtual ObjType type() const = 0;
  virtual size_t nChildren() const = 0;
  virtual std::shared_ptr<Obj> child(size_t i) = 0;
  virtual QString tableData(int column, int role) = 0;
};

class Group : public Obj { … };
class Leaf : public Obj { … };

Чем этот код плох? Всё дело в функции tableData().
1. Obj не должен знать, как выглядит таблица. И если, например, у группы вместо названия написано «17 листьев» — то он тоже не должен знать эти штуки.
2. Obj не должен подтягивать интерфейсные библиотеки — такие как интерфейсный фреймворк (Qt) и интернационализацию. Например, у той же утилиты мы когда-нибудь сделаем консольную версию для автоматической подгрузки данных.

Таким образом, назревает вторая таблица виртуальных методов. Основная, содержащая nChildren и child, пристраивается в код всегда. Дополнительная, содержащая tableData — только если имеем дело с графическим интерфейсом.

Можно, конечно, написать в QAbstractItemModel::data():

void MyModel::data(const QModelIndex& index, int role) {
  Obj* obj = toObj(index);
  switch (obj->type()) {
  case ObjType::GROUP: {
        // Куча всякой дряни с qobject_cast, switch(role), switch(index.column())
     }
  case ObjType::LEAF: {
        // Такая же дрянь
     }
  }
}

Но это громоздко и некрасиво.

Вот как сделать «по-объектному»?

Answer 1

[Антон Шаманов]

твой Оbj это DTO объект передающий данные загруженные ОD из базы в Widget/View для отображения

Comments

[Mercury13]

И как это реализовать?

[Антон Шаманов]

Mercury13,

про архитектуру, а не про компилируемость, верно?

это уже совсем другой вопрос, я не особо силен в десктопных приложениях. DTO - модель данных, ОD - объект для абстрактного взаимодействия с БД(CRUD), Widget/View - визуальный компонент отвечающий за отображение DTO

[Григорий]

При использовании интерфейса все что касается

// Куча всякой дряни с qobject_cast, switch(role), switch(index.column())

уходит в конкретного наследника интерфейса. При этом в модели останется что то вроде:

void MyModel::data(const QModelIndex& index, int role) {
  Obj* obj = toObj(index);
  return obj->tableData(index.column(), role);
}

При таком принципе добавление нового типа не потребует правки модели вообще.

[Антон Шаманов]

Григорий,
> При таком принципе добавление нового типа не потребует правки модели вообще.

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

[Григорий]

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

[Антон Шаманов]

Григорий,

вынесение логики из модели через интерфейс

это как? можно пример?

[Григорий]

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

[Антон Шаманов]

Григорий, я тебя понял, просто странная формулировка - интерфейс не служит для вынесения логики, он служит для множественной реализации

[Mercury13]

Григорий,

void MyModel::data(const QModelIndex& index, int role) {
  Obj* obj = toObj(index);
  return obj->tableData(index.column(), role);
}

От этого я и хочу уйти! В объектах данных Group и Leaf (вообще-то они у меня называются File, Group и Text, ибо прога занимается локализацией) не хочется держать ни форматирование таблицы, ни специфичные для графического интерфейса классы. Хочется держать их поближе к интерфейсу, а в консольных версиях проги просто убить.

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

[Mercury13]

Григорий, Cостояние у элемента есть и оно при любых обстоятельствах будет в ОСНОВНОЙ таблице методов. Но вопрос в необязательной функциональности вроде форматирования таблиц.

[Григорий]

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

QVariant getObjData(Obj* obj, int column, int role) {
  switch (obj->type()) {
  case ObjType::GROUP: {
        // Куча всякой дряни с qobject_cast, switch(role), switch(index.column())
     }
  case ObjType::LEAF: {
        // Такая же дрянь
     }
  }
}

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