Database Reference
In-Depth Information
The Proxy design pattern and its relatives
We have already mentioned some tasks that are explicitly related to traditional Proxy real-
ization. We will definitely employ a Proxy pattern when we have certain needs, such as:
• Establishing the local representation of a remote object that may exist in another
network segment or domain. This primary and classical role of Proxy has a long
history with COM/COM+/DCOM and CORBA.
• Protecting our object; a protective Proxy can be established where access permis-
sions can be verified. Reverse Proxy is one of the forms of protective Proxy.
• Establishing the placeholder for the object that we will create only upon the client's
request. This virtual Proxy can help us save a lot of physical resources.
• Implementing a smart, type-based Proxy that can check for the presence and state
of the object before passing the request, or that can act as a master objects referen-
ce table, counting number of object instances and destroying unused ones.
So, Proxy is a decoupling layer between the client and provider, safely plugging the re-
questor to the subject, allowing them to live or evolve independently at the same time. Can
it be described as an Adapter pattern then (another generic pattern)? Yes? No? Yes? Per-
haps more like maybe. Talking seriously, in classic design, adapters must (according to
their name and nature) adapt inbound signals to the receiver's capabilities expressed in a
contract. Thus, the Transformation and Bridging traditional patterns are native companions
of an Adapter, while Proxy is supposed to provide the same interface. Of course, nothing is
set in stone here, and we are just outlining the patterns relation according to generic POSA,
with some common sense for spice.
What if we want to extend the existing service contract, add a new capability, or change the
granularity for one or several contracts elements (functions and not data types)? In OOP,
it's similar to extending a class (subclassing), but we would still like to maintain decoup-
ling. As we know, OOP inheritance is a useful thing, but it certainly introduces tight coup-
ling in the inheritance hierarchy. What is good at the component-level architecture is not
exactly positive and desirable at the next higher level (service layer) within the composite
architecture, and further in the service inventory. Also, sometimes, this kind of enhance-
ment must be performed at runtime; therefore, OOP is not really applicable to its inherit-
ance.
In real-life situations, with so many variations added to the superclass through inheritance,
we can easily introduce a nightmare of the so-called "class explosion". These complications
can be resolved by the application of the Decorator pattern. The purpose of a Decorator is
Search WWH ::
Custom Search