I always try to apply the S.O.L.I.D principles and I really like the Qt toolkit but I find myself stuggeling all the time with the single inheritance rule.
If you are using multiple inheritance,
moc assumes that the first inherited
class is a subclass of QObject.
Also, be sure that only the first inherited class is a QObject.
How do you combine the single inheritance from a QObject rule and the Interface Segregation Principle.
I want to define the interfaces with signals and slots, but I'm not allowed to do this.
How do you get around this shortcomming?
Keep in mind that signals and slots are nothing more than functions that have special behaviors. Thus, you can use them to create interfaces.
For a full description of the process and a complete workaround for complex cases, see Qt Quarterly #15.
I don't think you can easily get around that with Qt's signal/slot mechanisms. You could try looking at either boost::signals or the sigc library, which are both more flexible in where you can place signals and slots. Be aware of possible namespace collisions with either library and Qt's signals and slots macros.
Related
I am working at the moment with Qt and discovered signals and slots. I think this is a Qt specific pattern. I am wondering if there are more Qt specific patterns like signals and slots. Are there any? Is there any specification about them?
In addition:
Qt's specific pattern are splitted in two parts:
Qt providing special classes for using design patterns like the Qt Quick module, Signal Slots..
The second part is the structure of some classes for example: QWidget
QWidget inherits from QObject which implements the composite pattern.
For further information i recommend this book: http://www.amazon.de/Introduction-Patterns-Prentice-Software-Development/dp/0132826453
There are some features which are unique to Qt or at least few implementations exist in other languages.
To name a few other than the signal-slot mechanism :
The Qt Quick module : Enables you to write QML applications and provides everything needed to create a rich application with a fluid and dynamic user interface. Some features are The Visual Canvas, User Input, States, Transitions And Animations, Particles And Graphical Effects, ...
Qt's Undo Framework : It's based on command pattern for implementing undo/redo functionality in applications.
The State Machine Framework : Can be used to effectively embed the elements and semantics of statecharts in Qt applications. It integrates with Qt's meta-object system; for example, transitions between states can be triggered by signals, and states can be configured to set properties and invoke methods on QObjects.
I have learned the basics of Qt and now interested in the depths of that pretty library. Please help me to understand:
Are the all classes derived from QObject?
Why is it possible to paint on a QWidget (and derived classes)?
What does the line return app.exec(); mean? What does exec() method do?
Are there virtual slots? And virtual signals?
Thanks.
All classes that need Qt's object model (e.g. by using signals and slots) must derive from QObject.
So that you can implement your own widgets, with a customised look. Any sensible GUI library would let you do that.
As documented, it enters the Qt event loop.
Slots can be virtual. Since signals do not have implementation (or rather, moc generates their implementation), they cannot be made virtual.
Qt has really good and extensive documentation, if you have more questions then they are probably already answered there. Start with Programming with Qt section.
I was wondering about the design pattern behind the signals and slots mechanism in Qt?
I am hesitating between the mediator and observer one?
Thank you...
QT's signals and slots is an implementation of the Observer pattern. If you want to know more about it, I recommend reading A Deeper Look at Signals and Slots which motivates it and compares it to Boost signals. Otherwise, there's always the QT docs.
If you want to use the Mediator pattern instead of the Observer pattern, it would be fairly trivial to do this using QT. You'd have to add a mediator class into the mix, and make it your observer of the events of interest; i.e. move the slots and most of your update logic from your regular observers to your mediator.
Qt library includes advanced meta-programming capabilities using they own preprocessing moc compiler. Does anyone knows, is it possible to create some kind of mix-ins via it? For example, i have a QString and want to add a method to it without sub-classing and changing existing code. Does Qt have such solutions for that?
I'm pretty sure that what the moc compiler isn't considered meta-programming according to the most common definition.
Furthermore, you can't add methods to a class using it.
Infact, in C++, you can never add methods to a class outside its declaration and moc (or any other QT utility) never actually touches the definition of the class. it only adds some meta-information to it and additional code which takes care of the signals and slots mechanism. This has very little to do with actual meta-programming.
I currently have a hierarchy of items based off of QGraphicsItem.
I want to move to QGraphicsObject instead so that I can put properties on my items. I will not be making use of signals/slots or any other features of QObject.
I'm told that you shouldn't derive from QObject because it's "heavy" and "slow".
To test the impact, I derive from QGraphicsObject, add a couple properties to my items, and look at the memory usage of the running app. I create 1000 items using both flavors and I don't notice anything more than 10k more memory usage.
Since all I am adding on to my items are properties, is it safe to say that QObject only adds weight if you are using signals/slots?
I think it depends on what you mean by weight. If you're not worried about the additional memory required nor all the extra methods and things that come with QObject, which sound like baggage in your case, then yes.
But, if all you need is a way to store some additional information, why not subclass QGraphicsItem and add a method or two that allow you to store the necessary data? By doing so, I think you'll better communicate the intent of your code, which seems more important than all of the above.
How about performance? There is extra cost in QGraphicsObject when calling setX/setY, and so on. You can go to QGraphicsItemPrivate::setPosHelper and find more details.