Given a 3rd party API with a very cumbersome object with many different responsibilities-- we decide to wrap using small, manageable, single-responsibility objects. This is the gateway pattern (I think).

So any time you do this there is going to be some kind of "connection" where you have to connect to the resource. Furthermore, calling applications may want to keep a single connection open and use it with multiple objects (those small, manageable, single-responsibility ones we created).

What form should this connection take? Should this connection be another object? Should it be passed it to the constructor of the small wrapper objects? Or, should the wrapper objects inherit from a connection object? Or aggregate it?

What about the special case where we can have only have only one connection per application?

  • Make it a private data member.
    – tp1
    Jan 3, 2012 at 17:53

1 Answer 1


Make a connection class with a public constructor. It should initialize an instance of the 3rd party object as a private field. The connection class should have factory methods that call private constructors of your other wrapper classes, passing its instance of the 3rd party object as a parameter.

  • What are the pros/cons of this approach? I see that it solves the problem of the calling application using multiple wrapper objects yet keeping the connection open.
    – Pete
    Jan 4, 2012 at 14:05
  • @Pete The pro is that it simply does what you want: allowing multiple objects to expose different aspects of the same instance of a 3rd party object. The cons are either inherent in what you want (you have to insantiate multiple wrapper objects to use the 3rd party API) or relative to the pros of other, as yet unspecified, approaches.
    – JGWeissman
    Jan 4, 2012 at 18:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.