ol**********@gmx.de wrote:
[...]
What I want to know If there is some "mechanism" so that I can avoid
all those "new" operators. I just do a "deep new" on the top level
class and all other instances for the sub-member fields are created,
too.
Well, what's your intent with respect to populating the contained classes?
For contained class instances, you must do _some_ initialization
explicitly. There's no automatic way for that to happen. By default
the reference to the contained instance is null, and it doesn't get to
be non-null unless you write some code that does that explicitly.
However, if you have some reasonable natural way to instantiate the
top-level node, then surely you also have some natural way to
instantiate the contained nodes, all the way down your containment tree.
For example, presumably you aren't instantiating the root node without
data to use to initialize it. In the same way, shouldn't you have data
before you go instantiating the contained nodes? And if so, wouldn't
the natural method be to simply go through the data as it exists,
initializing the relevant data structures as necessary?
I'm a bit confused by what appears to be an intent on your part to
initialize data structures for which you have no data yet. While I
think that I do finally understand the basic scenario you're dealing
with, it seems to me that the design requirement that the entire
containment tree be completely populated all at once is unnecessary and
is overcomplicating the implementation.
[...]
If there is a future change in one of the schemas I will have to
carefully adapt my contructors.
If there is a future change, won't you have to change all of your code?
For example:
And more worse there are three other
data trees besides "Balance" for which I have to generate classes from
the corresponding XML schemas. So that's why I'm asking if there is
some way to automate this process, so that I can just code:
Balance balance = new Balance(true); // this is the constructor that
will create all member instances
balance.general.effectiveDate = DateTime.Today();
balance.assests.stocks.subMember1.subMember11.subM ember111.subMember1111.someValue
= 1000;
The code above depends on the containment tree. If the schema changes,
that will presumably change the fields within the Balance class,
requiring you to change any code that refers to them. Thus, any code
referring to the properties "general" and "assets" needs to be changed
to address that change.
Basically, any change that would require some manual change to the way
contained members are initialized will also require some manual change
to the way they are accessed, and vice a versa. Trying to automatically
instantiate the entire tree with empty instances is not only likely to
be bad design, it's also solving a fairly minimal part of the overall
problem.
Pete