Вопрос по ООП: расширение функциональности QAbstractItemView.

[Akon]

Под дополнительной функциональностью я подразумевал манипуляции с самим абстрактным вью, который потом должен превратится в конкрентую реализацию либо QTableView либо QTreeView.

Это требует доступ к протектед интерфейсу QAbstractItemView.

То, что предлагает Igors, называется "декоратор" (паттерн такой). Он вам не подходит, поскольку позволяет декорировать только паблик интерфейс QAbstractItemView.

Вот это

//NOTE: T is some Q...View class
template<typename T>
class myMegaView:public T{
//some shared code

называется миксином (mixin - подмешиваемая функциональность) и основывается на одной из форм CRTP (идиома C++ такая, см. http://en.wikipedia.org/wiki/Curiously_recurring_template_pattern).
Оно будет работать.
Достоинство - есть доступ к протектед интерфейсу.
Недостатки: 1. инстанцирование под каждый наследуемый тип, т.е. раздувание объектного кода (несущественный недостаток), 2. не будет отдельного интерфейса, который соответствует подмешанной функциональности (существенный недостаток, если такой интерфейс требуется); данный недостаток устраняется, путем создания интерфейса и наследования от него, имплементацию интерфейса делает миксин.

Вариант от kambala (класс Common).
Достоинства/недостатки - инверсия предудущего варианта.

Все хорошо пока вам в собственном методе data() не придется использовать методы QAbstractItemView.

Если из класса Common нужно обращение к паблик интерфейсу QAbstractItemView, то делается кросскаст.

Код:

class Common
{
public:
    QVariant data(const QModelIndex &index, int role) const 
    { 
        QAbstractItemView* thisAsQAbstractItemView = dynamic_cast<QAbstractItemView*>(this); 
        thisAsQAbstractItemView->someMethod(...);
    }
};

В частности, кросскастом из Common к QObject можем выбросить любой сигнал из Common (разумеется, окончательный класс должен иметь такой сигнал):

Код:

void Common::setSomeProperty(int value)
{
	if (value_ == value) return;
	value_ = value;

	QObject* object = dynamic_cast<QObject*>(this);  // crosscast
	Q_ASSERT(object && "dynamic_cast<QObject*>(this)");

	bool ok = QMetaObject::invokeMethod(object, "somePropertyChanged", Qt::DirectConnection,
		QGenericReturnArgument(), Q_ARG(int, value));
	Q_ASSERT(ok);
	Q_UNUSED(ok);
}

Опять таки, в данном варианте нет доступа к протектед интерфейсу QAbstractItemView.

[Igors]

То, что предлагает Igors, называется "декоратор" (паттерн такой). Он вам не подходит, поскольку позволяет декорировать только паблик интерфейс QAbstractItemView.
...
Опять таки, в данном варианте нет доступа к протектед интерфейсу QAbstractItemView.

Может и не подходит (на то и обсуждаем), но аргументацию не понял - если унаследоваться от QAbstractItemView, то protected методы доступны, и методы хранимого указателя тоже

[ksergey85]

Шаблонные классы и миксин не подходит из-за ограничений moc.
Кросс-каст интересная тема, но в этом случае класс не будет порожден от QObject и рассчитывать на сигналы и слоты похоже также не приходится? Сигналы и слоты в дополняющем интерфейсе я создать не смогу?

[Akon]

Может и не подходит (на то и обсуждаем), но аргументацию не понял - если унаследоваться от QAbstractItemView, то protected методы доступны, и методы хранимого указателя тоже

Не понял мысль. Протектед интерфейс не доступен через композицию (QAbstractItemView* view_;).

Шаблонные классы и миксин не подходит из-за ограничений moc.
Кросс-каст интересная тема, но в этом случае класс не будет порожден от QObject и рассчитывать на сигналы и слоты похоже также не приходится? Сигналы и слоты в дополняющем интерфейсе я создать не смогу?

Ограничения moc не приятны, было бы хорошо, если бы поддерживалось множественное наследование от QObject. Тем не менее, проблема решается следующим образом: сигналы не объявляются в шаблонных классам, миксинах или в других базовых классах (Common). Сигналы могут объявляться только там где будет Q_OBJECT, т.е. в вашем окончательном классе (классах). Тем не менее, из упомянутых мест сигналы можно выбрасывать.

[Igors]

Не понял мысль. Протектед интерфейс не доступен через композицию (QAbstractItemView* view_;).

А если композитор и сам наследует QAbstractItemView ? (т.е. как бы 2 паттерна в одном). Может где-то заклинит, но рассмотреть стоит.

[ksergey85]

Хорошо с сигналами слотами потерпеть можно, не так их и много получается. В конце концов приоритетной является задача общего интерфейса.
Пока реализовывал методы с помощью кросскаста возникла проблема. В своем Common перекрыл виртуальный метод setModel() класса QAbstractItemView, но этот метод перекрывают и конкретные реализации, т.е. у классов QTableView и QTreeView он свой. Как мне добраться именно до QTableView::setModel() и QTreeView::setModel().

Имею в Common::setModel(QAbstractItemModel *model)
QAbstractItemView* thisAsView = dynamic_cast<QAbstractItemView*>(this); //crosscast
thisAsView->setModel(model); //вызов самого себя - рекурсия нам не нужна
thisAsView->QAbstractItemView::setModel(model); //статически слинкует с методом класса QAbstractItemView.

Как добраться до перегруженного метода? И реально ли это вообще?

[Akon]

А если композитор и сам наследует QAbstractItemView ? (т.е. как бы 2 паттерна в одном). Может где-то заклинит, но рассмотреть стоит.

В этом суть декоратора - внешний интерфейс тот-же, а поведение изменено (с меньшей связностью, нежели при открытом наследовании). Но, повторяю, вы не сможете получить доступ к протектед интерфейсу.

В своем Common перекрыл виртуальный метод setModel() класса QAbstractItemView

Это не перекрытие (виртуального метода). Это создание другого метода. Метод перекрыть можно только из наследника.

Код:

thisAsView->setModel(model); //вызов самого себя - рекурсия нам не нужна

Счего взяли? Это не рукурсия, это полиморфный вызов QAbstractItemView::setModel(). После кросскаста фактическое значение указателя будет другим - соответствующим положению QAbstractItemView в составном классе, соответственно, VMT будет восходить к QAbstractItemView. Кстати, еще ограничение мока - база QObject должна быть первой.

Если знакомы с COM или какой-либо подобной технологией, то кросскаст это аналог QueryInterface().

[ksergey85]

Все догнал. То есть по сути виртуальные методы из Common после такого кросс-каста становятся вообще не в счет? У них своя отдельная VMT?
Интересно только как я вызовом thisAsView->setModel(model) мог получить рекурсию при отладке. Но это не важно. Скорее всего дело в том, что мой метод принимает указатель не на объект QAbstractItemModel, а на объект класса-наследника.
P.S. бьюсь над тем как бы покорректнее внедрить слоты и сигналы в Common.