web hit counter
DCI Logo DCI Header Logo

DCI Home
Event Info
I.T. News
Press Room
Find It

The 'O Scale'

By Clive Boustred


A. Introduction

B. The Key Features of Object Orientation

C. Classification of Products - The "O Scale"

D. Summary

E. Conclusion

A. Introduction

There is much confusion in the market regarding objects. Objects are now the in thing. Most vendors claim some form of object-orientated capability in their product. There are, however, considerable differences between products and the level to which they support object-orientated concepts. The problem, however, stems from the basic definition of an object. What after all is an object?

While this is a relatively straightforward subject, we will reiterate object concepts in order to provide clarity and then define a reference model for gauging and representing a product's object-orientated capabilities.

B. The Key Features of Object Orientation

Firstly, we will ignore the simplistic view of an object and concentrate entirely on the software object model. It is, after all, software we are gauging.

Objects are made up of a few primary elements.

  • Interface Definition - The separation of Interface from Implementation

The most fundamental aspect to object-orientated techniques is the separation of interface from implementation which involves the support of standard interfaces being defined for all objects.

  • Classes & Instances

Classes form templates from which similar objects may be created. These objects being referred to as instances to that class. Classes may have global class variables and methods that may be applied to any instance of the class.

  • Instance Variables

The data itself - The object's state is defined by instance variables.

  • Methods

Methods define procedures that may be invoked against the variables. The methods define the behavior of the object.

  • Sub Classes, Inheritance & Multiple Inheritance

Sub classing provides the means by which a new class can inherit instance variables and methods from any existing class. Inheritance provides the ability for an object to inherit characteristics from an ancestor; multiple inheritance refers to many layers of sub classes.

  • Polymorphism & Object Type

Different object methods may be given the same name. This provides individual procedures for each object that may be invoked by a common call. For example invoking the method "Add" could perform different addition routines for each object. This generally simplifies the design of programs.

An object's type tells programmers the set of operations (methods) that can be performed on the object.

  • Encapsulation

To encapsulate an element and provide a controlled interface to the outside world, effectively creating an object out of the encapsulated element which could be legacy code or an object itself. Encapsulation provides the ability to modify the contents or methods within an object without affecting external dependencies, so long as the interfaces remain constant.

  • Messaging

Messages are used to communicate between objects. Messages might simply invoke methods on other local or remote objects. Messages may themselves be objects, containing both methods and variables, that are passed between different objects.

  • Object Identifier & Distributed Dynamic Binding

Object identifiers provide a unique identifier of the object. Distributed dynamic binding provides the ability to track and locate objects through their object identifier, regardless of their physical location.

  • Standard Objects or Frameworks

Reusable objects that come with or are available for any specific products environment..

C. Classification of Products - The 'O Scale'

Two simple object classifications have been previously used: Object-Based and Object-Orientated technologies.

Object-based technologies represent general technologies that allow the implementation of some or all of the object principals. However, they do not enforce object orientation.

Object-orientated technologies represent technologies that enforce the principals of object orientation: Inheritance, encapsulation, polymorphism, class structures, etc. SmallTalk, C++, Ada and most of the ORBs tend to fall in this category. The lines are not necessarily clear as it is possible to write a program that is not at all object-orientated with C++, while OLE, for example, does not support inheritance but is generally considered an object-orientated technology.

This basic classification method ends up being too vague for the many products on the market today. A more detailed classification based on the features of object orientation is required.

The following section details the O Scale, which may be used to determine a product's relative scoring based on key object-orientation features.

The O Scale

To determine a product's rating on the O Scale, use the following evaluation guidelines for each of the categories, providing a maximum score of one for each category.

1. Interface Definition - The separation of Interface from Implementation

This category forms a watershed for technologies claiming object orientation, while it separates proprietary technologies from industry standards. If a object cannot interact with objects from other vendors and products it provides a closed proprietary system whose future is questionable. There are two Interface Definition Language (IDL) standards: the OMG CORBA IDL and the Microsoft IDL (MIDL).

Firstly, determine if a product allows the separation of interface from implementation. If it does not, it is not object orientated. Secondly, determine the level to which a product supports IDL and MIDL.

2. Classes & Instances

This should be a simple rating to determine how well the product supports classes & instances.

3. Instance Variables

In this rating determine the methods and formats in which instance variables may be stored.

4. Methods

In this rating determine how easily methods may be implemented.

5. Sub Classes, Inheritance & Multiple Inheritance

Determine a product's support of inheritance and its ability to circumvent multiple inheritance problems.

6. Polymorphism & Object Type

This should be a simple rating to determine a product's support for polymorphism. You can also consider how easily an object's type may be determined.

7. Encapsulation

Determine a product's ability to encapsulate legacy or foreign elements.

8. Messaging

Determine a product's messaging capabilities, types of messages that may be transmitted, performance and message-handling abilities.

9. Object Identifier & Distributed Dynamic Binding

Consider the way in which object identifies are issued; if they are guaranteed unique; and determine the efficiencies and performance of the dynamic binding techniques.

10. Standard Objects or Frameworks

One of the key features of object-orientated technologies is that you may build software from pre-constructed objects. Determine what frameworks and individual objects are available. This category will strongly determine which products succeed of fail in the market.

D. Summary

You should now be able to determine a product's O Scale rating out of 10 by using the above classification technique. This will also help separate much of the marketing hype from a product's real ability to support object-orientated techniques.

E. Conclusion

While object orientation provides considerable advantages one will quickly find that it also raises new design issues. With polymorphism it is important to ensure that commonality and consistent naming is applied across all objects; that the object classes are correctly classified. If the technology does not eliminate multiple inheritance conflicts, procedures must be implemented to resolve fragile base class problem. Object re-use is only effective when the development staff is fully knowledgeable about what objects are available and how they may be applied, etc.

Also recognize that there are numerous different incompatible object models. Objects do not necessarily speak to each other. CORBA and OLE help to define standards that promote object interaction.

The goal of any technology is to enable domain experts to do the things they want to naturally, without requiring cognitive cycles to be expended on absurd syntax or inconceivable structure. Note: We used the term "domain expert" rather than programmer. A programmer has been an unfortunate necessity for the development of software. As with any software product, the ideas of the domain expert need to be converted to machine-driven code. This process has in the past required low-level programming skills such as the early assembler languages and 3 GLs. Very rarely do the domain experts themselves possess both domain and programming skills. Modern CASE tools are striving to make the program development task intuitive enough for any domain expert to easily master.

Object-orientated capabilities provide a strong foundation for implementing advanced distributed systems. The O Scale will hopefully help you in evaluating and determining which product suits your organizational and personnel needs.

Clive Boustred is featured at DCI's Software & Client/Server World.

  [home] [event info] [sign up] [exhibit now] [i.t. news] [press room] [find it] [help]

Copyright 1997 by Digital Consulting, Inc. (508) 470-3880
All event names are trademarks of DCI or its clients.