Объектно-ориентированное программирование с использованиемQT

[evilguard]

Решил создать топик, он скорее не по столько по библиотеке QT, сколько по C++ и ООП, но поскольку с QT связана так или иначе структура программы и ее особенности, поэтому думаю лучше это обсудить здесь.

У меня, собстенно появился первый вопрос
Есть приложение. На нем 2 основных виджета :QGraphicsView и  QTreeView. Они отображают одни и те же объекты - в графическом в виде, и в виде дерева - это вспомогательный вид. Когда щелкаешь по объектам правой кнопкой должно вызываться контекстное меню - как в QTreeView так и в QGraphicsview со стандартными командами - cut, copy, delete, properties и т.д.
В обоих виджетах я переопределяю contextMenuEvent():

Код:

void MyTreeView::contextMenuEvent(QContextMenuEvent *event)
{
	QItemSelectionModel *selectionModel = this->selectionModel();
	QModelIndexList indexes = selectionModel->selectedIndexes();
	QModelIndex index;

	QList<MObject*> objects;
	foreach(index, indexes)
	    if (index.isValid())
			objects.push_back( static_cast<MObject *>( index.internalPointer() ) );

	TContextMenuManager menuManager(this, event, objects);
	menuManager.showMenu();
}

Здесь для QTreeView. MObject - базовый класс для всех моих объектов. В этой функции я получаю список выделенных элементов и передаю их в объект класса TMenuManager - он в зависимости от конкретного типа объекта выводит контекстное меню в точке event->globalPos(). Таким образом я использую один и тот же кусок кода и для QTreeView и для QGraphicsView. В TContextMenuManager я храню actions, коннектю их к слотам. Но ведь теже команды cut, copy, delete должны быть доступны и в главном меню приложения - в меню edit. То есть все actions приложения, в том числе и те которые могут быть вызваны через contextmenu, должны быть определены в каком-то глобальном классе? Так получается? Этот глобальный класс делать Singletone? А коннектить эти actions тоже в этом классе к его методам? А методы эти как-то прикрутить к паттерну Command?
В общем вопрос непростой, хочется сразу продумать архитектуру, чтобы не мучаться потом. Программирование все-таки - это не накидать кнопочек на форму.
Заранее спасибо, тем кто откликнется. Предлагаю подобные вопросы обсуждать в этой теме.

[SABROG]

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

Код:

void MyNewClass::Method(int a)
{
         if (a == MyAction) // наше меню, вызываем наш обработчик
         {
         сделать что-то
         }
         else // вызываем стандартный обработчик
         {
         MyOldClass::Method(a);
         }
}

MyNewClass - наследник, MyOldClass - родитель

[evilguard]

Что то я не совсем понял, опиши то что ты делаешь. Я пытаюсь придумать механизм для обработки всех видов команд меню - контекстных, главного меню, и т. д. Должно ли это быть реализовано в одном классе или в разных. И как туда посылать данные, допустим указатели на объекты, с которыми будут производиться действия? Хватит ли для этого возможностей C++ - паттерны и прочее, или использовать дополнительные средства, QT в частности. И какие - сигналы слоты? Еще есть QEvent, с ними не разобрался еще - в их сторону копать?

добавлено спустя 17 часов 3 минуты:

 В общем я нашел то что мне нужно - исходник QT Designera. Щас изучаю, там все по ООП, в общем профессиональный код, осталось только разобраться  

добавлено спустя 1 час 9 минут:

 По мере изучения исходника дизайнера - возник вопрос - класс главного приложения надо проектировать вручную, как это сделали в дизайнере, или как предлагает интегратор в студию, с использованием самого дизайнера?

[zabivator]

И так и так можно.
По файлу, который сделает тебе дизайнер (ui - обычный xml) uic-компилятор тебе слабает обычный хедер файл.
А для твоей задачи лучше всего сделать сигнал и слот с одинаковой сигнатурой у обоих классов
signals:
   selected( const QList<bool>& )
public slots:
setSelected( const QList<bool >& )

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

[evilguard]

Думаю наилучший механизм в исходниках дизайнера. Просто я еще не добрался ло конкретной ее реализации. Там есть класс, в котором хрянятся все actions либо указатели на них. cutAction, copyAction там не создаются, их получают из функций из других объектов, я пока по цепочке не смог проследить, цепочка оборвалась на интерфейсном классе  :roll: