There's nothing wrong. But my set of classes it's a bit big. The
chain
of objects that contains others objects can be deep and produces lines
like
this
Me.Parent.Parent.Parent.Parent.Parent.Parent.Dataset
, and i must repeat the previous skeleton in every class. The code to do
this in all of the classes it's so great that i'm looking for an
alternative.
Without knowing your exact design, it's hard to say. But the first thing
that comes to mind is that it seems to me what you really need are some
helper functions. For example, rather than writing out the explicit
parent chain, have a loop that walks up the ownership chain until it finds
the class it's looking for (in your example, the one with the Dataset
property):
BaseObject objCur = this;
while (objCur != null && !(objCur is DatasetContainingClass))
{
objCur = objCur.Parent;
}
if (objCur != null)
{
// do something with ((DatasetContainingClass)objCur).Dataset
}
This requires that all of your objects inherit from a base object that has
a Parent property, of course, or at least some mechanism for returning its
parent.
Alternatively, each class could have a Dataset property that defers to its
parent's Dataset property if it does not itself have a Dataset property:
class Child
{
private Parent _parent;
public DatasetClass Dataset
{
return _parent.Dataset;
}
}
Note that I am taking as granted that your child/parent relationship
design makes sense. Again, without knowing the actual design, it's hard
to say that's true for sure. Looking at the rest of your post, this isn't
at all apparent:
Inheritance it's not an option because i'm already using
inheritance. I can use interfaces but it not avoid to write the necessary
code.
I don't think anyone mentioned inheritance as a solution, and for good
reason: inheritance and a child/parent relationship are completely
different. You wouldn't use one for the other. Conversely, if
inheritance is a way to represent the relationships between your classes,
then it may be that the child/parent relationship is the *wrong* way to do
it, which could explain why you have such an unwieldy design in the first
place.
Something to consider, IMHO.
.NET languages are very complete and i have wondered that this scheme
may be available using reflection. In nested classes i can use
reflection to
get the parent class in which the nested class is defined.
Reflection can get you the base class which a derived class inherits. I
don't personally feel that the concepts of "nesting" or "child/parent"
apply in this case (see above regarding how inheritance and parent/child
relationships are completely unrelated). Regardless, reflection isn't
going to get you anything here that a properly designed collection of
classes won't. If you are, for example, considering using reflection to
get at the various "parent" accessors for each class, it makes more sense
to define your class hierarchy so that anything with a "parent" inherits
from a class that has a "parent" accessor. Then you can do the
parent-searching code without needing reflection.
It's reasonable to think that reflection may be also used to know is a
given object is part of other as a property.
The "parent/child" relationship you're talking about (well, at least what
you *appear* to be talking about) is defined in your own implementation of
the classes. There's not really anything about the references that make
them parent/child-specific, except how you interpret them. So reflection
isn't going to automatically solve any sort of aspect of interpreting the
references (how, for example, would the reflection code know that one
reference in a class is that instance's parent, but that another reference
is not?).
I just don't see where reflection comes into it.
Pete