Improve your interface design, by first thinking about the type of class that you are designing...

Interface Design and Class Orientation

By Robin Sharp
September 22, 2002

This article is divided into the following pages:

1. Introduction
2. Function Oriented Classes
3. Object Oriented Classes
4. Service Oriented Classes
5. Component Oriented Classes
6. Correct Use
7. LIGHT Data and Architectures
8. Conclusion: Anorexic Interfaces

Introduction

Object Oriented design patterns have brought great benefits to software engineering. However, there are other types of design pattern that can be used to good effect in your applications.

When I hear discussions about Object Oriented design patterns being applied across an entire architecture, the O's in the OO acronym remind me of the eyes of animals who have frozen in a car's headlamps. The tendency to over-apply Object Oriented design patterns has led to the neglect of good lower level functional and higher level architectural design aspects of software.

This article separates interfaces into four different types of orientation, and then discusses each type with regard to its relevance to good architectural design.

The four interface types are: Function, Object, Service and Component.

It is important to make a conscious effort to distinguish between Function, Service, Object and Component oriented classes when designing software. A consequence of this is that it becomes a lot easier to build architecture neutral interfaces or reusable components. The code then becomes easier to use and test. Making a distinction between design patterns for types of classes and understanding where to apply them correctly can also have huge benefits on your code base and development times.

Before beginning, a few qualifications are needed. Classes do not equate to Object-Orientation. However, they are almost always spoken about in the same breath; in fact, Object Oriented design patterns most often should form the majority of code in reasonable sized applications. When people talk of Architectural design patterns they are often talking about Object Oriented design patterns at the architectural level. There is nothing qualitatively different about them.

Classes of Orientation

In this article, references will be made to the term HEAVY and LIGHT interfaces. We also refer to ACTIONS and ENTITIES (described below).

The word LIGHT in this article refers to the narrowness of the types in methods and interfaces. LIGHT interfaces only expose the language neutral types (e.g. String, int, double, Date) where there are standardised mappings, such as the SQL92, JDBC and COM.

HEAVY interfaces expose complex types with a large number of methods, and whose correct function may be dependent on call order. We also distinguish between ACTIONS and ENTITIES. ACTIONS refer to classes with no state, whilst ENTITIES refer to classes that hold state.

Given these classifications, a distinction can be made between four types of class and the Orientation of their design patterns. The table below illustrates the four types of Orientation.

Class Types and Orientation:

In this article, we will briefly define each of these four types of class orientation, and show how each would be used to define a simple File handler interface (for the sake of clarity I have left out the exception handling). Then we will discuss the correct usage of each type in more detail.

>> Next Page: Function Oriented Classes

Related Articles:

Component Oriented Thinking: Separating Data From Architecture

Automated Code Generation: The Fastest Way to Write Software?

<< Back to Design

<< Back to Software Reality