A couple of ideas:

Instead of passing specific types in your constructor, you could pass a
context object that contains the specific types (which could then be
accessed via properties off the context).  This can result is a less
brittle design, because each constructor takes same argument, and doesnt
break as you add/remove properties to the context object.

There is also the Registry design pattern ( see Fowler's Patterns Of
Enterprise Application Architecture for more info), which is essentially a
globally accessible lookup structure.

In the WinForms space, you could create an app-specific subclass of
ApplicationContext that provides the global hooks you need.  The
article 'Real World Applications Sample, Part 1' on MSDN gives some
details on how to do this.

Hope that gives you some ideas...

-John


On Tue, 22 Jul 2003 13:22:59 -0400, Woodard, John
<[EMAIL PROTECTED]> wrote:

>The subject doesn't quite explain it well, but here is what I am curious
>about.  My program designs usually include a repository of objects that
many
>parts of the application will need.  For instance, in a client/server app
>the link back to the server would be one such object.  A global dictionary
>of metadata items would be another.
>
>Back in the MFC days (gasp), I could put these items/collections in the
App
>class and each part of the application could get to them via AfxGetApp()
>with a cast back to the app class.  Components wouldn't do so, but other
>parts could.  Of course they always got to them through methods so I could
>control what the parts saw if necessary.
>
>I'm facing the same problem in my current application and I'm solving it
by
>passing these things around to everything as constructor arguments.  This
is
>painful because I have ended up passing things through several classes for
>the sole purpose of something down below using it.  This seems inefficient
>and it's hideous when you change the layout (which I've done a few times)
>because you have a million constructor arguments to fix/add to.
>
>Does anyone know a better way to do this?  It may not be pure OOD, but the
>pure approach in this case creates a maintenance nightmare.
>
>John Woodard
>[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

Reply via email to