Context Object

A context object encapsulates the references/pointers to services and configuration information used/needed by other objects. It allows the objects living within a context to see the outside world. Objects living in a different context see a different view of the outside world.

If you need to use a mail service, for example, where does it come from? You can imagine using a singleton, a global variable, a registration mechanism, a context object, creating a new service for every user. Any others?

Each approach has their own advantages and disadvantages.

Moved from SingletonPattern

So are there any patterns for avoiding singletons then?

Check out the MonostatePattern in C++; make all the data members static. I haven't used it at work but I know a guy who swears by it -- BillWeston

If I have a bunch of these 'there should be only one of these' type objects I generally throw them on a palette or workbench that gets passed around. Instead of passing a bunch of parameters in to classes I can just pass the Palette or Workbench. This also lets folks that are maintaining the code know my intention. -- FrankMcGeough

An alternative to passing a palette/workbench around (which couples the whole system to the palette) is to have a singleton Registry from which you obtain all the other singletons. Yes, the registry is a global variable but it's the only one (within that layer/subsystem) and all the things you get from the registry can just be normal easily-tested classes. Ensuring proper usage is just a matter of making sure that no-one ever calls the constructors of these classes but instead use the registry.

Note that this alternative to raw singletons is also known as RegistryPattern (in Fowler's PatternsOfEnterpriseApplicationArchitecture) and even mentioned in passing in the GoF book itself.

See ContextObjectsAreEvil, ExplicitManagementOfImplicitContext, PowerBox

CategoryContext