Well, Jim. . .

No matter how I try to slice it, it does seem to come down to IF YOU ARE GOING TO BE DEPENDENT ON INSTANTIATION/FIRING ORDER, THEN YOU HAD BETTER DOCUMENT THIS FACT VERY VERY WELL so that it is clear and obvious to any who may follow.

To me the introduction of terms like "mediation pattern" or "mediation object" or "mediation class" *may* help a bit, but the real key is to make it as clear and plain as can be that the dependency is there.

I surely cannot argue with the concept of concentrating any such dependencies in as few places (one being best) as possible, for the reasons you cite. But it *ALSO* takes WARNING NOTES (in my humble opinion) throughout the app's documentation to remind people of that case.

Thanks for answering,
Jim N

>>Jim,
>>
>>You are confusing me somewhat on this issue. . .
>>
>>In one instance you decry the idea of having one object dependent on the instantiation/firing order, and on the other hand you speak of design patterns with mediators and delegation.
>
>Jim,
>
>The destinction is as to whether the point upon which your design is dependent is under your control or ooutside of your control. With a dependency on instantiation sequence you do not have full control. Other objects can be added or objects may be removed and that will alter the instantiation sequence. These changes could be done by you or by someone else.
>
>Interdependency between objects is a situation that should be avoided, but it cannot be completely non-existant otherwise nothing would ever happen in the application because no object would ever send a message to another object (which in itself is a dependency). The reasons to avoid a dependency on instantiation sequence are;
>
> 1) it is not under your complete control
>
> 2) it renderns your design non portable to other OO language which may have a different instantiation sequence
>
> 3) the sequence is easily altered as a side effect of some other action (adding or removing controls)
>
>The reasons a mediation pattern is more desireable are;
>
> 1) in the design of the mediator class you are aware of its interdependencies and can account for those issues
>
> 2) all dependent code is located in one place making it easier to fix any dependency related problems that may arise
>
> 3) the myriad of objects need to know about only one mediator object, the mediator object is the only object that needs any knowledge of all of the others