Ram�n and everyone else,
Well I've been thinking about this for quite some time now and I must say, it's interesting :)
I'm glad I was not the only one to find this interesting.
I guess for many people the question now is - what exactly are you trying to accomplish with this structure? I suppose you are not trying to use CC instances to keep an audit trail of BB instances, are you? ;)
Perhaps with a clear idea of what is being accomplished a better model can emerge.
As I was typing my previous post, I made a bet with a co-worker that this would probably the the question asked :) I should have written an example to the problem. Here it goes. It might be a bit tricky to understand without the background... let's try.
Say, we have class ProcessDefinition. This class has fields such as: ProcessWeight, ProcessSequence, ProcessMaxValue, ProcessMinValue, ProcessAutoScore, ProcessDisplayInMaster... and a few more. This class is defined at Corporate level. The 'Big Guys' define this criteria set.
Now, we have a class called Process, which actually holds the data that this process definition implies, so we have: ProcessID, ProcessValue, ProcessAutoScore... and so forth.
That would simply work. The deal is that we have multiple regions, levels in between the corporate definitions and the actuall Processes. So, the Process instead of being tied to a ProcessDefinition is tied to a ProcessInstance. This ProcessInstance is what class CC would be. It is a class that a regional manager, or a local manager creates for processes. This gives him the chance to use the corporate ProcessDefinition but extend it a bit or override some values. Kinda like inheritance does :) It's an open/closed system, in Bertran Meyer's lingo. It there are changes to the global policies, then this changes are reflected in to the lower ProcessInstance classes, unless they have specifically overriden the value.
I hope we are thinking about the problem in a wrong way, because we've come across the issue in more than one place already. Or maybe, we can figure out a good way of doing it here! (Me thinks of Desing Pattern?)
I like the solution that you have more than I like the solution that we had come up with. It involves a bit less redundance of code. Still, it seems that any time you add a field to class BB, class CC has to be 'informed' about this new field. I whish I could stay away from duplication of knowledge, but maybe there is no way to do it.
Or idea of re-writing CC to be almost an exact copy of BB and of overwriting the getters in CC to see if they had a local value is really nasty. We have some working code doing that already, and I loath it.
Thanks for the reply... and I hope you don't stop there :) Hope others jump in too.
Daniel.
