The Carbon Java Framework  

Carbon Development

Use of Patterns

Printer Friendly Version

Author: Greg Hinkle (ghinkl at
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.

Patterns in Carbon

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.

Service Locator

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.


Resource URL

Industrial Strength Factories
Sun's J2EE Patterns

Copyright © 2001-2003, Sapient Corporation