When I was a boy I was told that anybody could become President. Now I'm beginning to believe it. -- Clarence Darrow
Cookie provided by www.update.uu.se

The Umbrella Design Pattern on Franks Internet Playground.


An Object-DesignPattern for the Development Process.

Name of the pattern

Umbrella, take it with you, or it will rain.


Structural Pattern
Ad: If you were searching for a market umbrella or patio umbrellas, mjjsales.com has a wide selection for every occasion.


Programming agains large libraries and frameworks is a big help. No need to reinvent the wheel and fiddle with the details how to get it round. On the hand there is nothing constant but the change. So even the libaries you are programming againt will be subject to change, forcing you to rework your interfaces. Yes, pure OO should make interfaces more stable than classical programming ever could, but the higher complexity of many OO systems brings the problem back by the pure quantity of interfaces involved.

Things change, also interfaces between distant subsystems of system in development change or the usage patterns of an (otherwise unchanged) API changes over the time. Be prepared for the change. Before you start and do your own stuff, start to prepare for the change.


Use the Umbrella when at least one of the following is true:

The main point of the Umbrella is, to start with it early. Later in the project when you realize you need such a thing, you'll realize the need for implementing a Facade, a Wrapper or a common Decorator, but the Umbrella can be there in early stages of development, ready to mutate in one or more of the above types.

The pattern is very similar to John Vlissides Generation Gap, but where Generation Gap tries to cope with changes in automagically created classes, the Umbrella copes with similar problems in external libraries or frameworks.

Structure and Participants

It's all fairly simple: Two larger systems. A class Remote and one or more subclasses of Remote called Local-1, Local-2 and so on.

The Umbrella consist of a interposed class LocalRemote which subclasses Remote and all Local-x classes subclass LocalRemote instead of Remote directly.


Derivation and communication between the Local-x and Remote class (of course you will have many those situtations in larger contexts) will be solely going through the LocalRemote Umbrella


The following things make the Umbrella usefull: Though the Umbrella is easy to start with (i.e. it could often start as a empty class with no implementation at all), there are some special considerations:


Trivial, simply start with a simple empty abstract class in a project. The point is

Sample Code

- Missing, sorry -

Known Applications

In GUI Progammin gone may end up umplementing several subclasses of the same Library-Control. These are the main applications of the Umbrella known to me.

When starting an application in a Servlet environment, don't subclass HttpServlet immediately, but subclass YourAppServlet which is a subclass of HttpServlet.

Related Patterns

As mentioned above.

The nature of the Umbrella is that it is very likely to mutate, since it often starts as a mere nothing. Depending on the ongoing development the Umbrella might turn into one or more of the following Patterns:

Note the last case is especially occuring when the remote system is changing, while the other cases might also happen for reasons of avoiding redundance when interacting with the remote system. No change of the remote system is required.

Another point is, that a Umbrella can be a mixture of all 3 above mentioned pattern. Though when it actually is a large scale mixture of all three, it might most likely will be itself be close to a refactoring target.

As mentioned before the Umbrella is also somewhat similar to the Generation Gap Pattern by J.Vlissides.


spieleck.de  | Franks Internet Playground  | Franks Practical Theory  | Send email

Access count: 5921,  gener ated Thu Feb 23 21:36:28 CET 2017; prev access=Wed Feb 22 15:26:20 CET 2017; s ervlet up since Fri Jan 20 01:53:19 CET 2017