Qt-interest Archive, December 2007
Alternative for multiple inheritance.
Message 1 in thread
Hello, qt mail list.
Don't get scared with all below, it is just tree view model.
Suspect I have:
class Tree : public QObject, public QGraphicsItem {...};
class SubTree : public QObject, public QGraphicsItem {...};
void Tree::addSubTree ( SubTree *tree ) {...};
I wish to make
class FileTree : public Tree, SubTree {...};
and be able to do:
FileTree a;
FileTree b;
SubTree c;
b.addSubTree ( c );
a.addSubTree ( b );
With QGraphicsItem and QObject in inheritance I get multiple ambiguous, and
even after hiding most of functions I still have problems with
QObject::connect function.
Qt suggest to use something like:
class FileTree : public QObject, public QGraphicsItem
{
private:
Tree m_tree;
SubTree m_subTree;
}
But if so I am not able to make
FileTree a;
Tree b;
b.addSubTree ( a );
because a is not a SubTree object.
What is the solution for such cases?
--
[ signature omitted ]
Message 2 in thread
> Suspect I have:
> class Tree : public QObject, public QGraphicsItem {...};
> class SubTree : public QObject, public QGraphicsItem {...};
> I wish to make
> class FileTree : public Tree, SubTree {...};
it's a very bad idea to create a class that inherits from multiple
QObjects-derived classes.
Why don't you make Tree inherit from SubTree? Isn't it just a special
case of a subtree? (one without parents?)
Or even more: why do you need different classes for Tree and SubTree?
Cheers,
Peter
--
[ signature omitted ]
Message 3 in thread
On Thursday 20 December 2007 17:20:29 Peter Prade wrote:
> it's a very bad idea to create a class that inherits from multiple
> Objects-derived classes.
>
> Why don't you make Tree inherit from SubTree? Isn't it just a special
> case of a subtree? (one without parents?)
> Or even more: why do you need different classes for Tree and SubTree?
>
> Cheers,
> Peter
I think, I will follow your suggestions. The reasons to make things separately
was:
1) my Tree was only to hold SubTrees, but now I need other option.
2) only few Tree realizations needs SubTree as parent.
3) Tree very (!) differs from SubTree in most cases.
So the best option was multiple inheritance as if I would make class
MouseAlarm from Mouse and Alarm. And it basically is bad thing to add Alarm
functions to my Mouse, or to derive Alarm from Mouse.
--
[ signature omitted ]
Message 4 in thread
Alexei Sergeev ha scritto:
> 1) my Tree was only to hold SubTrees, but now I need other option.
But a subtree also holds subtree, isn't it?
> So the best option was multiple inheritance as if I would make class
No, multiple inheritance is generally symptom of bad design :-) You can
solve a multiple-inheritance needing with composition or, at least,
interfaces (a pure-abstract class that do not enherits from QObjects).
> MouseAlarm from Mouse and Alarm. And it basically is bad thing to add Alarm
> functions to my Mouse, or to derive Alarm from Mouse.
But Alarm could be an interface and so not derived from an ancestor of
Mouse. Or, compose the MouseAlarm with an Alarm object and derive the
MouseAlarm class from Mouse only.
--
[ signature omitted ]
Message 5 in thread
On Thursday 20 December 2007 18:48:34 ing. Federico Fuga wrote:
> But a subtree also holds subtree, isn't it?
Just bad alias in my mail. It was rather TreeItem at first.
It was Article, articles was combined in to Feed, then I added Categories,
that contains feeds and other categories. Never mind)
> No, multiple inheritance is generally symptom of bad design :-)
Don't think I have reasons not to believe You, but is there any stuff
explaining Your point of view to read?
> You can
> solve a multiple-inheritance needing with composition or, at least,
> interfaces (a pure-abstract class that do not enherits from QObjects).
I was thinking about all off those options before writing here. Just was
hoping one could tell some "common gold solution", so I don't need to rewrite
all code 3 times before get the right way.
> But Alarm could be an interface and so not derived from an ancestor of
> Mouse. Or, compose the MouseAlarm with an Alarm object and derive the
> MouseAlarm class from Mouse only.
Yes, it is the way. Just in case I already have Alarm and Mouse, then I don't
want to make Alarm abstract and copy/past all implementation to MouseAlarm,
that is my case. More than that I need to remake alarms already presented it
client code.
Thank You for Your attention anyway! I think I will use abstract classes or
combine 'item holders' and 'items' to make universal 'item that can hold other
items'.
Is architecture below ok?
class AstractItemsGroup;
class AbstractItem;
// contain basic paint and move virtual operations and slots common for simple
items.
SimpleItem : public QObject, public QGraphicsItem, public AbstractItem;
// reimplement basic group paint, group move, collapse operations and slots
common for ItemGroups.
AdvancedItem : public SimpleItem, public AstractItemsGroup;
AstractItemsGroup::addItem ( AbstractItem* );
AdvancedItem a;
AdvancedItem b;
SimpleItem c;
a.addItem ( b );
b.addItem ( c );
--
[ signature omitted ]
