In a perfect world we would all have the time, energy and inclination to learn the object model of all the components which we wished to use. This however is certainly not the case and almost everyone is under increasing pressure to meet ever shortening deadlines whilst increasing the level of functionality offered. In order to address this need we have introduced "wrappers" into our component development process.

What are Wrappers?

We will first discuss the definition and use of the special case of "primitive wrappers" before we move onto "wrappers" in a general context.

Primitive Wrappers

A "primitive Wrapper" is used to wrap our often rather complex object structures with classes which only admit methods which return and use primitive types. The concept of a wrapper is equally applicable on each of the object oriented component enabled development platforms which we support and we will apply wrappers within each of our platform component suites.

In order to illustrate the use of wrappers let us consider the Equation Solver component which finds solutions to functions of one real variable. One of the possible wrappers (in this case) would be to wrap the underlying object structure with a wrapper class for which the solution to all functions of polynomial type could be found by ONLY passing to a method within the wrapper class primitive types. For example, the polynomial could be described by send two arrays of doubles and integers where the elements of the double array corresponds to the coefficients of the polynomial and the integer array to the corresponding powers of the variable used within the polynomial expression. That is, instead of having to delve within the object structure and create an object which represents the polynomial you are interest in from the function superclass, you are able to solve this problem just calling the appropriate method directly.

General Wrappers

The essence of a primitive wrapper is to wrap a software asset (object, components,..) and present the functionality in a form which is convenient for a given development purpose. However, since we require that the wrapper only returns and uses primitive types, a primitive wrapper will always essentially wrap an asset as a service. This may be appropriate for wrappers which are directly exposed to exterior processes, for example GUI or Web services. Though for more internal development work it does have the distinct drawback of making the wrapper inflexible in terms of possible application.

In order to provide more flexible wrappers we weaken the definition by allowing the wrapper to take values as primitives and objects. This allows a more general type of wrapper which may assist in the development process.

Let us give an example based upon the pricing of financial contracts. Say within the underlying object structure we have one object which represents each of the possible contracts available (i.e. swaps, options, caps, and so on...). We also have a number of objects which represent the pricing models applied to these contracts (i.e. Black-Scholes, AGM, Vasicek and so on...). At the base object level it is convenient to keep these entities separate in order for the class library to remain flexible and efficient. However, for a given development purpose it may be convenient to wrap these objects so that a contract and its preferred pricing model are associated by being wrapped within the same object. This wrapper class when instantiated will allow for a contract to be precisely defined and for this contract to be priced with the preferred pricing algorithm from within the object instance.

The general wrapper allows associations between objects to be described, these associations will almost certainly contain domain specific information (as in the case above) and allow for the development process to be enriched by packaging the objects in a fashion where the way in which they should be applied with the business domain is implied by their structure.

Balancing Flexibility and Custom Wrappers (without charge)

Wrapper classes though being quick and easy to work with do not have the power and generality of programming a components object model directly. For this reason we will always offer full access to the underlying object model even when a comprehensive collection of wrapper classes is provided. Another issue with wrapper classes is that there may be an infinite number of possible wrappers (e.g. in the case of implementing functions) and therefore we are unable to implement all possible wrappers. To address this issue we offer (in almost all cases) to write new custom wrapper classes (without charge) as needed for your given problem.

The Onion Layer Approach to Software Granularity

There is much debate within the developer community around the issue of the appropriate level of granularity of the various aspects effecting objects, components and services. It is however generally excepted that as building blocks the components should have a coarser level of granularity than the objects, and the services should have a coarser level of granularity than the components. Our view is that granularity of a software artifact effects many levels of the softwares architecture. In particular, the number and structure of classes within a component or service, the number an methods within these classes and the number and type of parameters and return types which these classes contain.

Therefore, since several orthogonal parameters effect the granularity of a software artifact. The granularity of the software artifact itself should be seen as lying on a continuous spectrum rather than existing on discrete bands such as: objects, components, services. This granularity spectrum ranges continuously from the raw objects through to services which generally exhibit few methods with many parameters of primitive type, and beyond. Moreover, these differing layers of granularity can be selected via wrappers in accordance with the development project at hand.

Our Implementation of the Onion Layer Approach

Though granularity may be a continuous spectrum we are forced to make choices as to the finite number of granularity bands we can access by layers of class wrappers of our software objects, components and services. The choice of where these extra bands lie is down to domain specific issues and developer taste. The domain matter will suggest convenient "sweet spot" levels at which the balance between generality and easy of use makes the business problems at hand particular amenable. The developer themselves will have their own preferences as to the level of granularity which makes them the most productive for the type of problem they are addressing.