Component-Oriented Thinking: Separating Data From Architecture

By Robin Sharp
May 26, 2002

The paper is divided into the following pages:

1. Introduction
2. Component Oriented Thinking
3. Data Binding
4. Domain Oriented Software (+ Conclusion & References)

Introduction

This is the third part of a series of articles on component oriented languages from a Java perspective.

Part one examined the evolution of software languages and concluded that Java is currently in its inefficient stage, where the number of API's available is blooming. C# is in its acceptance stage, where the API's are still immature but there is a coherence to them.

Part two looked at how languages evolve but move closer to the problems, and looked at the concept of component oriented languages. The article concluded by suggesting that Sun add a restrictive class modifier to Java, to enable a class to declare that it was a data component or an architecture component.

This article looks at the concept of the separation of data and architecture in more detail, to show how Java would benefit from a clearer distinction between the two types of components.

Component oriented software also separates the interface from the implementation. This is expressed in the component oriented literature as separating the message from the method. In other words the interface from the implementation.

To clarify, component oriented design separates the architecture from the data. This is expressed in component oriented literature as separating the module from the types. In other words the machinery from the product, the sausage from the machine, the form from the administrator, the envelope from the postman. Component oriented software is a natural.

An interesting issue that is raised by the separation between data and architecture components in component oriented programming is whether component oriented software represents a regression by separating data from behaviour. In fact it doesn't. Component oriented software makes the separation between data and architecture, but not the separation between data and behaviour.

A good example of this is validation. From a component oriented perspective, validation is a behaviour that belongs to both data and architecture.

For example, a data component may be validated for nullablity, string lengths or data ranges, whilst an architecture component may be used to validate a data object against a function, or data store; in other words verification. Traditional object oriented programming does not make this distinction: as a consequence it is common to see 'validation' frameworks torn by not wishing to separate two types of behaviour.

Component oriented software is not clearly described in the object oriented design patterns literature.

For example, Design Patterns (GOF) make the distinction between creational, structural and behavioural patterns but they do not make a distinction between data and architecture. In fact the Design Patterns book pretty much ignores the distinction, except by reference in some of its examples. The words component, data and architecture are not even mentioned in the glossary. A lot of these issues were addressed 2 years after the publication of Design Patterns by a book called Pattern Oriented Software Architecture: A System of Patterns [Buschmann et.al. 1996].

>> Page 2 (Component-Oriented Thinking)

Message Forum:

Please let us know what you think of this article...

Post a new message

Am I the only one?
Rob Dickens http://lafros.com
J2SE1.5 (Tiger) to support 'metadata'
Rob Dickens

Post a new message

<< Back to Programming

<< Back to Software Reality