| Use of Patterns |  |
Author: Greg Hinkle (ghinkl at sapient.com)
Version: $Revision: 1.2 $($Author: araman $ / $Date: 2003/05/05 07:42:36 $)
Created: January 2002
|
| | |
This document describes the uses of patterns within the Carbon Component model.
It is directed at developers and advanced developers with an understanding of
UML and standard design patterns such as those in the "Gang of Four"
(GoF) . The Carbon Overview is expected pre-reading.
|
Carbon utilizes and recommends patterns in three different ways. The first is
that Carbon is implemented using patterns. Commonly recognizable factories and
other patterns are used within the core implementation of Carbon. The second is
that Carbon provides tools and services to support the use of patterns. An example
of this is the manner in which the Component Service can act as a Factory and
Service Locator for any user written component. The third is in the way that we
as a Framework Team will guide teams. This typical work, that our team has done
for years, is toward guiding teams in the implementation of their applications.
We have in the past recommended certain pattern implementations such as Session
Facade to create the best use of Application Server functionality. In this manner,
the Framework Team should continue to help suggest and aggregate best practices
as created by both them and the teams they support.
|
|
The factory pattern and similar patterns such as Maker, provide a standard
mechanism for building objects through a defined interface. These patterns,
known as creational patterns, tend to be easy places for extension and enhancement
as you can have a factory use logic or configuration to determine the object
to build. The primary benefit of this pattern is to abstract the creation of
objects from the client code that uses them as well as supporting additional
efficiencies of allowing the service to define its creation. The Singleton Pattern
utilizes this type of functionality as a specific case to control resource usage.
One of the primary uses, by the Carbon Core, is to allow extensions of parts
of the architecture such as assistants and the generic delegate.
|
|
Carbon also provides a strong guidance for use of the Service Locator pattern
in which a client uses configuration to retrieve a particular implementer for
a requested service. The primary functionality of this pattern is the decoupling
of client from service provider. In Carbon, the Service Locator functionality
is provided through the Lookup Service and the static Lookup class
functionality. One of the ways this will improve the Framework is by allowing
services to be constructed and specified simply through configuration.
|
|
The carbon component model utilizes the concept of decorators to attach
additional capabilities to live components. Components are constructed
from Component Templates which are configurations of the additional
decorators to be used by a component. Carbon uses this template to
lookup factories that construct decorators that are exposed through
the component facade, acting in a sense like pseudo-multiple
inheritance. This capability is strictly designed to expose orthangonal
functionality and not additional business capabilities through a
component. To inherit other business capabilitites you should still
use Java inheritance.
|
|
Carbon component decorators may also be capable of intercepting calls
to a component through a component interface. On construction, the
component factory subsystem builds a chain of interceptors that will be
used to handle all calls to a component. For each invocation, the calls
are made to the first interceptor which may optionally take some
action and then forward the call on to the next interceptor. At the end
of the chain typically an invoker will be used to execute the call on the
original target object. This target could be the components implementation,
also known as the Functional Implementation or it could be one of the
decorator delegates.
|
|
The singleton pattern has often been used in the past to centralize resources
of all types. The Singleton Pattern is a creational pattern the controls access
to the implementation. The Framework has often used the Static Singleton Pattern
in order to create Manager Services or single points of entry into a group of
functionality. This has in the past led to the benefits such as not needing
to create new instances of shared, stateless objects. Some of the examples are
the SqlServiceFactory, the ConnectionManager, the Lookup Manager and the Cache
Manager.
With Carbon, each of the above services, manager's is no longer necessary and
we can create each version of the specified type as a specific, Carbon Managed,
Singleton. This should reduce the code and complexity of each of these services
while supporting the robust management and other features of Carbon.
|
|
| | |
This is a list of concepts and ideals that the Java
Framework Team uses as a guide to good design and development. These concepts
help to keep us building robust, pluggable software that is still maintainable
and manageable.
|
Encapsulation is the inclusion of one implementation within
another so that the included functionality not apparent. The idea is that this
will simplify the usage of the encapsulating service while allowing future
modifications to that service so that its implementation may be changed. This is
one of the primary ideals of our Framework and is the primary reason that our
complex services remain usable even with such complex implementations and such
robust pluggability.
|
|
Consistency is the concept of ensuring that there are as
few different ways of accomplishing a specific objective as possible. In
specific relation to the coding design principle, this means that Carbon has
only a single way to build factories and in fact includes a template that should
always be used. This consistency allows both framework developers and clients
of, to learn and understand a few simple concepts and then reuse them across the
architecture. This is one of the most important aspects in creating a widely
used API and is was one of the primary drivers behind the move to Framework 4.0
and the Carbon Model.
|
|
Reuse is a simple concept, but in fact, quite difficult to
manage. Software is developed with a specific purpose in mind and the stresses
of normal project lifecycle are in conflict with the additional effort and time
required to reuse code.
|
|
Pluggability provides a standard mechanism to alter
function points in a provided service and to allow that alteration to happen
through simple configuration rather than code alteration.
|
|
|
