Daniel
I would probably do as follows
Have one Process class for all locations with the following additional
properties
1) LocationID : Type : LocationClass
So that each process is locationalized (can't think of better term).
2) LocalInfo : Type %String Collection : Array
This is where additional local process info would go.
d oref.LocalInfo.SetAt("InfoA","LocalProcessInfoA")
d oref.LocalInfo.SetAt("InfoB","LocalProcessInfoB")
This would also have the followingl benefits.
a) No limit to the number of Process Parameters (LocalProcessInfo) at local
level
b) These parameters can be different for different processes at the same
location.
c) These paramters are user-defined at run time.(Of course these can be
standardized by each location).
Overall
1) All process instances are in one class - may be on a single server.
2) To get info from all locations, the big guys need only use one SQL
Statement with a single pass.
3) You can prevent (if needed) the small guys and elfins from a location
poking their noses into processes at other locations.
4) Need not worry about inheritance.
Hope this helps.
Regards
--
Sukesh Hoogan
e-Linear Enterprise Solutions
Bombay, India
http//personal.vsnl.com/sukesh_hoogan (updated : June12 , 2004)
'
Daniel Santa Cruz <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> 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.
