Confusion regarding parents and set/get functions
-
For a project I'm currently working at, I need three forms (with corresponding classes): A, B and C. Form A will read data from a file and store it in a QVector. Clicking a button in form A will open up form B (parent: Form A). Clicking a button in form B will open up form C (parent: Form B). Form C will need to access the data I read in form A, and to avoid using global variables I've been told to create a separate class and use set/get functions to access the data from other forms.
In form B, I can access the data simply by using @parent->MyClass.GetValue()@. However, from form C I'm somehow unable to step up two levels, to the "grandparent". My idea was to access the data from form A by something like parent->parent()->MyClass.GetValue(), but it doesn't seem to recognize the class of the second parent. I get the error message "'class QObject' has no member named 'PresDat'".
Have I misunderstood the concept of parenthood, or is there anything else that I've missed? Would I need to create set/get functions on all levels, so that form C calls form_B->get() that in turn calls form_A->get? Or is there a better way of accessing public functions of a parent of a parent?
Edit: I should mention that I've already considered passing on the QVector as an argument between each form, but I'm not too happy about this approach. There is a chance that I in the future want to add more steps between A and C, and also potentially transport more data between various forms. I would want to avoid a project where I pass a myriad of data as arguments every time I create a new form, simply because "I will need it later".
-
Hi,
From a pure design point of view, accessing something from a parent object should be avoided, even more from a grand-parent, this breaks orthogonality. You make widget C dependent of widget A and if you modify A you might have to modify C.
The suggestion was good, keep your data access encapsulated in it's own class (could be a model for example) and give that class to your widget C. A will know how to fill it and C how to read it, this allows you to change which widget/object loads the data without having to change C.
Hope it helps
-
[quote author="SGaist" date="1373903545"]Hi,
From a pure design point of view, accessing something from a parent object should be avoided, even more from a grand-parent, this breaks orthogonality. You make widget C dependent of widget A and if you modify A you might have to modify C.
The suggestion was good, keep your data access encapsulated in it's own class (could be a model for example) and give that class to your widget C. A will know how to fill it and C how to read it, this allows you to change which widget/object loads the data without having to change C.
Hope it helps[/quote]
Hello, thanks for the quick reply!
Yes, I see what you mean about why it should be avoided if possible. But I don't think I quite understand what the structure would be like.
I'll create a class "MyClass" to hold my data, including set/get functions, and a public instance "MyClass Data;" of this class in form A where I store my data. How do I then, in form C, tell the program to use that particular instance of MyClass, except by parenthood?
This might be a quite naive question, but I have very limited experience of OO programming. Are there any good examples online of how to use set/get functions to warrant the need for global variables? I've been trying to find some myself, but no luck.
-
There are several possibilities, the first being to use a setter in your widget C. If you are planning to share the data between several widget you might also consider the MVC pattern (explained in Qt's documentation) it might be a little harder to setup but might simply greatly things after.
If OO is not yet in your skill basket, I would recommend getting a book about it, you will gain time and understanding
-
Thanks, I'll look into it! I have a few books, but on one side of me I have a boss thinking that any more than one working day spent learning is a waste of time, and on the other side a computer science graduate with very firm opinions on which coding standards should be followed...
-
Then give them both "The Pragmatic Programmer" to read. They are both holding to truth that are shallow.
Complex subject are not learned in only one day and it takes more to master them.
On the other side, one good way to understand how something works in code is programming test units (that can also help to debug later)
