Design issue with constructor arguments

Hi all,

I'm writing a C++ program and I've come across a design issue that I
seem to keep getting but I dont know if it has a name or something.

I am writing a library which is to be used by some client code. In this
library I have a single front end class which acts as a kind of facade
into the library. Clients can instantiate one of these to gain the use
of the library. Internally, I have many classes and one of these is a
special processing class which invokes callback function supplied by
the client.

Thus this processing class has functions to allow the client to
register and unregister callback functions but they dont get to use
this class directly - those functions are mirrored on my front end
class. So the idea is that the front end class instantiates the
processor and fowards requests to register callbacks. All good so far.

The problem that I am experiencing is that internally, the classes that
need to use this processor are buried way down in the internals of the
library. There are something like five classes in between the front end
and the one that actually needs a reference to this processor.
Currently, I instantiate the processor and then pass a reference to it
via constructor calls. This pattern is repeated through these five
classes - each passing the reference down to the next class. But these
classes in the middle really shouldn't have any knowledge of the
processor.

It would be a lot easier to describe this with a simple diagram so I
hope I have made sense! Basically, I want class A, to create an
instance of class B and give it to class X, without having to give it
to class C who gives it to D who gives it to E etc etc and finally it
gets to X.

Any ideas?

Caroline Middlebrook

.

Relevant Pages

  • Re: Design issue with constructor arguments
    ... seem to keep getting but I dont know if it has a name or something. ... I am writing a library which is to be used by some client code. ... special processing class which invokes callback function supplied by ... I instantiate the processor and then pass a reference to it ...
    (comp.object)
  • Re: LSP and subtype
    ... Client is indifferent to vs. but does not want to invoke foo() if the instance in hand is just a Base ... Moreover, even if Base is not abstract, the client only sees the interface of Base, so why should the client ever care about the runtime type of the object he deals with? ... Example: .NET provides the FileStream class http://msdn2.microsoft.com/en-us/library/y0bs3w9t which is concrete and can therefore be used on its own. ... I don't see how this backs your assertion that one should not be able to instantiate Base classes. ...
    (comp.object)
  • Re: Raising Event on the Server and handling it on the Clients.
    ... > I am trying to do it with .NET Remoting using delegates, ... abstract in C#) that contains the callback function must be ... > defined in a common assembly that both client and server have access to. ... The abstract class needs to have a specific ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: What about CAO?
    ... One possible solution to this is to extend your shared assembly with an interface for a SAO object. ... It needs a single method which returns a new instance of the CAO, ... Then get a reference of this object on the client via GetObject (you do not instantiate the object, you get a proxy of the existing one from the server - so it will work with the interface only on the client). ...
    (microsoft.public.dotnet.framework.remoting)
  • Re: Connecting Out of Process Servers via COM+
    ... it would create a Dispatcher-Object first and registers ... how would I instantiate the teh object at the client? ... If two Clients at the same time are requesting the COM+-Server, the requests ...
    (microsoft.public.vb.com)