| 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 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.
Local-x
and Remote class
(of course you will have many those situtations in larger contexts)
will be solely going through the LocalRemote Umbrella
Local-x classes. 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.
Remote classes 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.
LocalRemote
for 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 LocalRemote more 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 YourAppServlet
which is a subclass of HttpServlet.
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.