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

[ksergey85]

Здравствуйте. Бьюсь над таким вопросом. Он скорее из области ООП, но имеет отношение и Qt.
Имеем два стандартных Qt-шных класса QTableView и QTreeView, порожденных от одного абстрактного предка QAbstractItemView. Возникла необходимость добавить некоторую функциональность, которая имеет одинаковую реализацию как для QTableView так и для QTreeView. Естественно два раза писать одинаковые методы, перекрыв классы QTableView и QTreeView не хочется. Я перекрываю общего родителя QAbstractItemView, дополняю класс нужной мне функциональностью, и теперь мне необходимо перенести эту дополнительную функциональность в оба дочерних неабстрактных класса с помощью механизма наследования. Как я могу это сделать?
В данный момент блуждаю около виртуального множественного наследования, наступил на такие грабли: классы QTableView и QTreeView порождены от QAbstractItemView не виртуально, поэтому никак не выходит заставить компилятор создать только одну копию класса QAbstractItemView, чтобы он перестал ругаться о неоднозначностях при использовании методов QAbstractItemView.
Как я понимаю в ObjectiveC для подобных ситуаций придуманы категории. Что тут можно придумать на плюсах?

[mutineer]

отнаследовать QTableView и QTreeView от твоего класса, вместо QAbstractItemView. Ну и на обычнах Qt либах это работать не будет - придется делать либо статическую сборку, либо везде носить собственную версию Qt либ с собой

[Igors]

Ну делаете QAbstractItemView * членом Вашего класса и заряжаете его по обстановке QTableView* или QTreeView*. Чем не устраивает этот стандартный прием?

[ksergey85]

Ну делаете QAbstractItemView * членом Вашего класса и заряжаете его по обстановке QTableView* или QTreeView*. Чем не устраивает этот стандартный прием?

То есть имеете в виду композицию. Но тогда я не смогу напрямую обращаться к методам QAbstractItemView как к методам моего класса. Или не так?

[kambala]

можно попробовать вынести одинаковую функциональность в отдельный класс и множественно наследоваться от этого класса и QTableView/QTreeView. должно получиться что-то типа такого:

Код

C++ (Qt)
class Common
{
public:
    QVariant data(const QModelIndex &index, int role) const { return "hello"; }
};
 
class TableView : public QTableView, public Common
{
public:
    QVariant data(const QModelIndex &index, int role) const { return Common::data(index, role); }
};
 
class TreeView : public QTreeView, public Common
{
public:
    QVariant data(const QModelIndex &index, int role) const { return Common::data(index, role); }
};

вот только я не знаю как там будет с сигналами и метаобъектной системой в целом

Ну делаете QAbstractItemView * членом Вашего класса и заряжаете его по обстановке QTableView* или QTreeView*. Чем не устраивает этот стандартный прием?

То есть имеете в виду композицию. Но тогда я не смогу напрямую обращаться к методам QAbstractItemView как к методам моего класса. Или не так?

можно написать методы-обёртки, которые просто вызывают нужный метод из QAbstractItemView. или вообще сделать это поле public и обращаться напрямую.

[ksergey85]

Похоже я все-таки нашел очень похожую тему: http://www.linux.org.ru/forum/development/4181710. Там решение удовлетворяющее меня частично найдено. Можно зафигачить шаблон класса, где и описать всю общую для классов функциональность.

Цитата:
//NOTE: T is some Q...View class
template<typename T>
class myMegaView:public T{
//some shared code
};

А свои виджеты наследуете так:

class myWidget:public myMegaView<QTreeView>{

};

[DmitryM]

У шаблонных классов не может быть сигнал/слотов.

[ksergey85]

To kambala:
Все хорошо пока вам в собственном методе data() не придется использовать методы QAbstractItemView. Под дополнительной функциональностью я подразумевал манипуляции с самим абстрактным вью, который потом должен превратится в конкрентую реализацию либо QTableView либо QTreeView.
На счет оберток - я ж замучаюсь ко всем нужным мне методам писать обертки. И потом если мой класс не будет прямым наследником QAbstractItemView то я не смогу его использовать как полноценный вью там где Qt ожидает от меня вью.

[Igors]

То есть имеете в виду композицию. Но тогда я не смогу напрямую обращаться к методам QAbstractItemView как к методам моего класса. Или не так?

Свой класс наследуете от QAbstractItemView, да, придется "делегироваться", может обильно. Ну ничего страшного, можно потерпеть

[ksergey85]

У шаблонных классов не может быть сигнал/слотов.

Откуда информация? Можно ссылку?

[ksergey85]

То есть имеете в виду композицию. Но тогда я не смогу напрямую обращаться к методам QAbstractItemView как к методам моего класса. Или не так?

Свой класс наследуете от QAbstractItemView, да, придется "делегироваться", может обильно. Ну ничего страшного, можно потерпеть

Не совсем понял, что вы имеет в виду. То есть мне нужно наследоваться от QAbstractItemView или все-таки сделать QAbstractItemView частью моего класса в виде член-данного? Если второе, то опять же возникает проблема, что мой класс не будет наследником QAbstractItemView, а значит не будет наследником Qwidget и вообще QObject со всеми вытекающими последствиями.

[ksergey85]

Кстати шаблоны не подходят. Сигналов/слотов не будет да. Он же вообще не будет наследником QObject  
UPDATE: туплю - будет. Вопрос прежний почему не будут работать сигналы и слоты?

[Igors]

То есть мне нужно наследоваться от QAbstractItemView или все-таки сделать QAbstractItemView частью моего класса в виде член-данного?

"и" (вместо "или")

[DmitryM]

У шаблонных классов не может быть сигнал/слотов.

Откуда информация? Можно ссылку?

Это ограничение у moc

[ksergey85]

То есть мне нужно наследоваться от QAbstractItemView или все-таки сделать QAbstractItemView частью моего класса в виде член-данного?

"и" (вместо "или")

А можно увидеть как это должно выглядеть. Я что должен буду перекрыть все виртуальные функции обертками над моим QTableView/QTreeView? Не совсем догоняю механизм.