I am trying to port/re-write GUI made using Nucleus Grafix to QT on Linux.In Nucleus code there is a control class which is the base class for the rest of the controls like Button,Editbox, radiobutton etc.This base class uses Nucleus API's and control structs to maximum.My question is whether to port/re-write the base class or make the control classes like Button to inherit from QPushButton.Which is better?
Oftentimes for a situation like this, it is easier to do dual-inheritence. It may not be the best long-term solution, but it will probably get you to your desired result the fastest. Remember that the QObject-derived class has to be the first one inherited from, and to avoid diamond inheritance with QObjects.
Related
I'm trying to invent a GUI testing library for Qt. The library is meant to work remotely, so that I can run tests on mobile devices over WiFi. It should simply provide API for visible element's functions.
It should be extensible. In Qt, any visible GUI element is subclass of QWidget. I can hard-code handling for QPushButton (eg. clicking) or QLineEdit (writing text) but note that user can define his or her own QWidget subclasses, some of which may represent completely new kind of GUI.
In Java, I could solve this because class type is essentially a variable of Class type. So I could have:
public static void registerTestingHandler(Class<? extends java.awt.Component> GUIObject, Class<? extends TestingApi> apiHandler) {
...
}
The TestingApi would then be some basic interface which would accept messages as strings, eg: handler.doAction("click");
C++ doesn't have this kind of reflection. I also learned that it's impossible to get class' constructor address which could be used for this purpose. I think the whole design should probably look different in C++.
Therefore the question is: How do I allow user to register abstract handlers for specific class instances?
What is in your opinion the best way to implement similar dialogs in Qt5 without duplicating the code?
This is the problem: having two "slightly different" data structures, with many common parts, implement two "slightly different" QDialog to handle the user interaction.
We have two structures:
class DataA {
public:
int one, two, three;
bool x,y;
SubdataA subA;
}
class DataB {
public:
int one, two, three;
bool x,y;
SubdataB subB;
}
SubdataX is some other structured data we need to handle in the GUI. The two QDialog should handle the common fields the same way, while SubdataX must be handled by specific parts. The code should also make some operation on the data structures, and provide output files. This part is quite easy.
My question is, what are the best strategies to implement this? The objective is to have elegant code that should be quite easy to maintain and as most readable as possible. The framework is Qt, so the solution should be tailored to Qt with qdialog layout in UI files, since the gui layout is too complex to design it by code.
Thank you.
I'm not sure what you mean by "difficult to manage the ancestor class". I think I understand you want a polymorphic input to determine the layout of a dialog box. Is this assumption correct?
For example, given the following classes, you're able to use a dynamic cast to influence the behaviour of a dialog box.
class IData {
public;
int one, two, three;
bool x, y;
};
class DataA : public IData {
public:
// more data in here
};
class DataB : public IData {
public:
// more unique data in here
}
Now, assume you have written a dialog box with a function signature
void configureDialog(IData *data) {
DataA *dataA = dynamic_cast<DataA*>(data);
if (dataA) {
// configure what parts of the QDialog to see here
}
DataB *dataB = dynamic_cast<DataB*>(data);
if (dataB) {
// configure other parts of the QDialog you want to see
}
}
Which would allow for polymorphic configuration of a single QDialog box.
As Tyler Jandreau stated, a possible solution is to use polymorphism.
But this requires a careful planning of architecture and class inheritance, because to avoid using downcasting and a huge and unmaintenable number of switch() cases, you need also to use polymorphism on the GUI classes.
As View/Model architecture requires, the data classes will be mimicked by the control/Gui classes.
Data classes will be implemented using an ancestor, abstract class CommonData that includes the common "fields", and two (or more) concrete data classes derived from CommonData through inheritance. My first idea was to use composition instead, but this would pose other issues when implementing the gui.
So DataA and DataB are derived from CommonData.
On the Gui side, the structure is similar, but due to lack of inheritance support of the UI form classes generated by Qt's uic, we cannot use inheritance. My first guess was to use Template Metaprogramming, and implement the ancestor class as a Template class, but though it worked on the C++ side, moc refuses to parse that class and generate the moc_X file when the Q_OBJECT tagged class is a template.
So we are going to use a mix of inheritance and composition.
This is the architecture: a "container" GUI class (ContainerDialog) implements the GUI for the CommonData class; a PluggableInterface abstract class will define a set of operation (we'll see which below); a set of concrete classes derived from the latter will implement the GUI logic for the remaining classes.
So the ContainerDialog loads a ContainerDialog.ui form as a "standard" QDialog, and manages all the interface with CommonData. His constructor , or a setter will receive a CommonData pointer, remember that CommonData is abstract and cannot be instantiated.
The specific fields are managed thorugh specific graphic components that are "plugged" in the ContainerDialog gui. For example, a method defined in PluggableInterface will insert the QWidget derived component in the ContainerDialog gui. The classes involved are, for example, ComponentA1, ComponentA2, ComponentB, etc...
The use of the abstract interface PluggableInterface and the UI components will prevent the ContainerDialog to know what kind of concrete class are in use, and all the necessary code to instantiate the specific classes can be implemented using some creational pattern (Abstract Factory, Prototypes, etc...)
I am making a win32 api program. I first created a base class called WinClass and inherited like a dozen other classes from it. Now I need to create a derived class from two classes inherited from base class WinControl and WinHandler.Since I intend to make many more derived classes out of the original dozen, I'll have to use virtual inheritance on like every class inherited from WinClass.So is there any way to do this without using virtual inheritance?
Learn how to avoid overuse of inheritance at all. For example, read this article
http://berniesumption.com/software/inheritance-is-evil-and-must-be-destroyed/
A good start to learn how to get things done the way you want it (with the correct use of inheritance) is the book "Design Patterns":
http://c2.com/cgi/wiki?DesignPatternsBook
I first created a base class called WinClass and inherited like a dozen other classes from it.
And there's your first problem. If WPF has taught us anything, it should be that inheritance is not necessarily the best model for GUI design.
So is there any way to do this WITHOUT using virtual inheritance?
Yes: don't have WinControl and WinHandler be derived from WinClass. You haven't said what these do, so I can't offer any specific advice about them. Really, it seems like what you need is a "has a" relationship rather than the "is a" relationship that inheritance brings.
Also, there's no need to use boldface for class names. Just use the code tags that StackOverflow provides. Nor is there a need to SHOUT in bold-face.
I'm making a game GUI API where each widget inherits from the Widget class. I was thinking, when others make there own widgets, they might not be fully satisfied with the base class. They might want to add getTheme() for example. Would it be a good idea to make all my widgets virtually inherit from Widget then so that this is possible?
Thanks
Just because the user would add their own methods to a child class doesn't mean you need to use virtual inheritance. You would use it if, in your library, you have a single base class with multiple children, and people could inherit from multiple child classes at once (for example mixin rather than substitution).
To resolve a diamond-shaped inheritance problem. (B and C both inherit from A. What happens to A's attributes in D that itself inherits from B and C?)
A client of your library could see a RedWidget and a FlyingWidget, and might want to combine them into a RedFlyingWidget.
User would have to specify one of the base classes to be virtual when inheriting. But that is not responsibility of a library maker.
OOP flows better with single-implementation inheritance, so that's what I'd use throughout a library.
There are also "upside-down inheritance" trees, as described by Alexandrescu's excellent "Modern C++ Design." They allow clients to pull in more functionality in a form of mix-ins that are called policies.
Programming with policies allows for greater ability to combine functionality, at the expense of syntactical cleanliness. Think STL implementation, for example.
When is virtual inheritance a good idea?
That's a design question.
For your Widgets, I would say Yes, multi-derived classes should have the option to be just 1 Widget.
Whenever there is a possibility that the users of your library are going to use several classes from your library as a base class (ie derive from them), you have to use virtual inheritance. In other words, it is a good idea to use it in your case.
I had faced the problem. In my C++ hierarchy tree I have two branches for entities of difference nature, but same behavior - same interface. I created such hierarchy trees (first in image below).
And now I want to work with Item or Base classes independetly of their nature (first or second). Then I create one abstract branch for this use. My mind build (second in image below).
But it not working. Working scheme seems (third in image below).
It's bad logic, I think...
Do anybody have some ideas about such hierarchy inheritance? How make it more logical? More simple for understanding?
Image
Sorry for my english - russian internet didn't help:)
Update:
You ask me to be more explicit, and I will be.
In my project (plugins for Adobe Framemaker) I need to work with dialogs and GUI controls. In some places I working with WinAPI controls, and some other places with FDK (internal Framemaker) controls, but I want to work throw same interface.
I can't use one base class and inherite others from it, because all needed controls - is a hierarchy tree (not one class).
So I have one hierarchy tree for WinAPI controls, one for FDK and one abstract tree to use anyone control.
For example, there is an Edit control (WinEdit and FdkEdit realization), a Button control (WinButton and FdkButton realization) and base entity - Control (WinControl and FdkControl realization).
For now I can link my classes in realization trees (Win and Fdk) with inheritence between each of them (WinControl is base class for WinButton and WinEdit; FdkControl is base class for FdkButton and FdkEdit). And I can link to abstract classes (Control is base class for WinControl and FdkControl; Edit is base class for WinEdit and FdkEdit; Button is base class for WinButton and FdkButton). But I can't link my abstract tree - compiler swears.
In fact I have two hierarchy trees, that I want to inherite from another one.
Update:
I have done this quest! :)
I used the virtual inheritence and get such scheme (http://img12.imageshack.us/img12/7782/99614779.png). Abstract tree has only absolute abstract methods. All inheritence in abstract tree are virtual. Link from realization tree to abstract are virtual. On image shown only one realization tree for simplicity.
Thanks for help!
C++ supports multiple inheritance, so you can have the union of (2) and (3), making sure that AbstractBase is always declared as a virtual base class.
Without knowing the real meaning and purpose of the various classes, it's difficult to offer any better advice.
It's not clear from the description if this would work for you but typically classes with a common interface would define the interface in AbstractBase and then have concrete instances inherit directly from that (FirstItem, SecondItem).
Why the extra indirection(s) in your examples? What's expected to be in AbstractItem, FirstBase and SecondBase?
For using different implementations of one interface, on could use:
the Bridge Design Pattern
You might couple this with a Factory Design Pattern so as to construct your two implementations differently.
However, it may look too simple for your classes architecture.
But as the comments under your answer say: it is difficult to imagine the job/role of your classes with such names. You should be more explicit, so as we can think of a precise design.