|No cookie due to java.net.ConnectException: Connection refused|
|Cookie provided by www.update.uu.se|
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.
It's all fairly simple: Two larger systems. A class
one or more subclasses of
The Umbrella consist of a interposed class
Remote and all
Remoteclass (of course you will have many those situtations in larger contexts) will be solely going through the
Local-xclasses. This happens for example when the remote system solves a more general class of problems as needed by the local system. This lets the Umbrella actually become Decorator.
Remoteclasses might be captures by changing the Umbrella and therefore leave your central classes unchanged. Again the Umbrella mutates in a hybrid of the allready mentioned other patterns.
LocalRemotefor each of those which might bloat your class modell by many classes without any implementation. In this case the point is the wise decision which classes get an Umbrella in which don't. Actually one
LocalRemotemore usually doesn't hurt the system as much as functionality programmed multiple times in local classes. Many local classes affected by a change in the remote class. Modern Systems like Corba or EJB usually generate half a dozend Java classes to describe the aspects of one single conceptual class. From this perspective the Umbrella is cheap.
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
which is a subclass of
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.