Database Reference
In-Depth Information
to "mash up" the capabilities of a concrete class with new capabilities to present a new
compound contract. Usually, this is done by creating an abstract decorator, which is a
proxy to the main object (in fact, it's an exact replica of the abstracting class), and con-
crete Decorators that enhance the actual object's methods. So, here, the role of Proxy is
clearly visible and the link between Proxy and Decorator is apparent (compare this with
the Adapter-Proxy relations). With regards to the SOA design, the Decorator pattern is im-
plemented as a composite at the component level, and this pattern can be applied in the
composite application layer as well.
The Decorator pattern is also linked to the adapter's pattern implementation. This relation
is not straightforward though. It is better to see it from the Decorator's downside. Al-
though we have replaced the inheritance by composition (except Abstract Decorator-
Proxy), we can still end up with tons of concrete Decorators. Yes, we have achieved a
reasonable level of decoupling, but at what cost? We still have a lot of static modules (that
is, enhanced interfaces) to maintain; wrap them into Decorators and explicitly instantiate
them. It would be good if we could instantiate them blindly through the interface without
knowing about concrete implementation. Actually, this is possible by using the Factory
Method pattern, which provides an interface to create (access) objects without knowing
their realization. Of course, all objects in a collection must be of the same type. We can go
one step further in our abstraction and implement the Abstract Factory pattern on the top
of concrete factories in order to access/instantiate different object collections. Now, decor-
ators along with Abstract Factory will not only decouple a caller from the object (pro-
vider) with the enhanced interface, but it will also allow us to access this interface without
knowing its explicit specification dynamically.
So, a Decorator as a wrapper could work well together with Abstract Factory. Adapters
can be seen as a wrapper as well. In real life, we don't always deal with only one adapter
(unfortunately), as we have many interfaces to adapt. Thus, our collection of adapters
must be abstracted first and then accessed in a dynamic way, without the knowledge of an
actual consumer/provider implementation and depending on the invocation directions (re-
member, we have northbound and southbound sides of the same ESB). In this case, Ab-
stract Factory can be evolved into Adapter Factory.
This pattern is not exactly from the traditional pattern catalogues (for SOA, visit
ht-
tp://soapatterns.org/
, or for OOP, check out
http://www.oodesign.com/
), but its necessity is
obvious. Although every physical adapter is an individual wrapper to the concrete API
(not always legacy), transformation, validation, filtration, and enrichment are common
functions associated with the traditional adapter pattern. It is also obvious that JCA tech-
nology/protocol adapters (for file/FTP, JMS MQ, AQ, and in most cases, DB) also have a
Search WWH ::
Custom Search