Re: Composition hierarchy implementation?
Michael DOUBEZ wrote:
Ross A. Finlayson a ?crit :
I wrote up a little program that generates C++ from a simple input
format, a list of relations. Basically I'm trying to understand
"composition hierarchy" vis-a-vis "inheritance hierarchy."
The usual question is between composition and *private* inheritance.
For that particular question, see the FAQ:
http://www.parashift.com/c++-faq-lite/private-inheritance.html#faq-24.3
or (seeing some french in your question):
http://jlecomte.ifrance.com/c++/c++-faq-lite/private-inheritance-fr.html
[problem statement]
I could not understand what you want to achieve, I suppose you have a
polytree represnting a hierarchy of concepts like
streamable...(shouldn't they be orthogonal ?) and interfaces.
And from a description language, you want to add nodes in this tree and
finally generate classes used for statistical analysis.
And I don't see the relation with the problem that follow.
Anyways I wonder if there are some examples of generating iterators
over a composition/containment/aggregation hierarchy. This is about
typing each element contained in a composition hierarchy to provide
iterators over its elements, then it could very easily be treated as a
tree in graph algorithms, in an automated manner.
If think Loki gives some examples of iterators with different
strategies. I think Boost.Graph should have something to add too.
So: inheritance hierarchy, use built-in inheritance mechanism and
generally use pointers to allow polymorphism. Composition hierarchy,
good practice?
That depends on what you want to achieve (surely part of what I did not
understand earlier in your post).
Good practice is :
- public inheritance is a "IS A" relation-ship
- composition and private inheritance are a "HAS A" relationship.
So I would say that for concepts such as streamable, public inheritance
is the relevant choice (especially since you want to handle the objects
isomorphically) but for attributes, composition is more likely to be the
good choice.
Michael
Thank you. I am just trying to learn a way to maintain a database, in a
composable manner. The mention of polytree seems useful, that seems to
describe the combination of upwards and downwards inheritance and
composition hierarchy. Yet, in consideration of the node of that kind
of polytree itself, it contains references to four different sequences
of the same types, it is an irregular type, so if it had a composition
relation with itself then it would be cyclic.
class node{
vector<node*, attribute*> composition_children; // <- this type is
composed of these elements
vector<node*, attribute*> inheritance_parents; // <- this type inherits
from these classes
vector<node*, attribute*> inheritance_children; // <- these types
inherit from this type
vector<node*, attribute*> composition_parents; // <- these types are
composed of this type
type m_identifier; // <- this is the type
};
As a graph, each node, attribute pair indicates an edge from node to
node. A simple specification of a node's composition might be along the
lines of
node = (node attribute)+ (node attribute)+ (node attribute)+ (node
attribute)+
That isn't enough specification to indicate proper identifiers for the
members for their semantic meaning, in trying to indicate what be
graphically meaningful iterators over the composed elements, in terms of
their meaning.
While that may be so it's very useful for a regular composition
hierarchy, which holds true for many data types. So, there might be
interfaces defined for constructable, creatable, cloneable; comaparable;
stringable, ostreamable, where the interfaces indicated would have code
generated for them, that might be listed in the inheritance listing for
dynamic casting up to those types, or simply generated blind to match
convention, eg "Big 3", orthogonal interfaces and also extensions of
them. I'm interested in implementing something along the lines of an
istreamable interface, as a convenience for acceptable, which is
parsable and so on, in terms of something like boost's "spirit" which
has an interesting composable parser system, or in terms of parser
expression grammar (PEG) or so. Yet, while there might be a native
encoding for a type so that it would be reasonable there to encapsulate
the parser for that type within the object or a nested hierarchy, there
are many data types that would vary /sequences in their parsing.
Anyways in terms of the statistics, to each of the objects in the
composition hierarchy there is going to be attached a "statistical"
object, where the relation among those will match the relation among the
composition and inheritance hierarchy, eg, the statistics for an
instance would be the root of trees out through the parents and children
in inheritance and composition. Those would often be scalar (or
algebraically composite) values like reals or complex numbers, or more
often counts, integers counts, in enumerated types discrete statistics,
and would simply be the lowest/atomic/elementary compositional types.
They could be counts or measures over natural language constructs. In
inherited types, specialized subtypes with the same compositional role,
they would have both the default statistics, and also possible
specialized statistics. Then, there is some consideration of developing
statistics over ad hoc series, that is about taking a sequence of
objects, besides refining the statistics over the population, to refine
them over various windows , in an ad hoc manner to begin, but later in a
sense maximizing the information in successive refinement of the
statistical content. Then those instance statistics would also go into
the statistic object.
Anyways back to implementing a composition hierarchy, I guess in a sense
it is about the notion of object persistence, object/relational mapping
type considerations. It seems that it would be a good idea to indicate
the composition hierarchy with regards to a sense of matching a database
implementation, of course towards abstraction away from actually
considering the implementation, in generating the code to present a
convenient object layer. It would be good to have, even for efficient
use of memory, normalization of the composed objects contents.
Basically I want to find a nice way to implement, here in C++, object
hierarchies for effectively representing data, and to have it work well
with the object-relational mapping, and have it be easily specifiable so
that for example a tool could read an XML schema and generate a
specialized C++ object hierarchy for that kind of objects with the
database mapping, or vice versa, there are probably some great tools for
that already, although I don't know them. There are also many various
modeling tools that would have this kind of notion, besides database
designers and so on. Some of those might generate rich C++ objects with
the nested iterators and so on.
I think it's funny that the decomposed type B of A, A has-a B, but
derived type B of A, B is-a A, they're reversed, in a sense, composition
and inheritance.
Merci beaucoup pour votre reponse,
Ross F.