Alas, the world has not yet come up with universal, efficient, distributed, widely accepted object-oriented databases. Thus for most systems implementations today, even those where an object-oriented language can be used, more traditional systems such as relational databases need to be used.
Implementation in non-object systems does not mean that object-oriented design is inappropriate; object-orientation is a method which does not constrain the implementation model. However, there is a loss in continuity between design and implementation, and extra work in the translation. As this translation has to take place in other methods (e.g. SSADM), there is no relative deficiency, just a lack of relative efficiency in the translation of designs to implementations.
Most systems require persistent storage of information over time. When a C++ program ends, so do its objects. Therefore there is a need to store the objects externally in some form. Databases provide a number of features:
Basically, the attributes of a class need to be stored in some form of data structure. For Pascal (or Ada) these would be records, for C they would be structs, and for a relational database, these would be relations.
In a relational database, the constraints of the representation
format may mean that one object decomposes into many linked relations.
Normalisation may increase the dispersal. By viewing object models
as a superset of entity-relationship models, it is possible to
use the normal translation into a relational decomposition.
Storing more than one object means that the records in a traditional language will have to be grouped into some structure, such as an array or linked list. There is a need to manage the creation and deletion of objects in some way. For arrays, some counter of objects created will be needed, and perhaps some way of marking free elements in the array. Linked lists are a bit easier in some ways, but they involve the use of pointers which can be difficult to debug.
If a language like Fortran is used, where there is minimal data structuring, then a class of objects will have to be managed as a group of arrays. This is likely to be very tedious (but then most programming involving complex data is tedious in Fortran).
The changes in syntax are apparently small, but significant. Suppose that we wish to create an employee object in C++. We would create a class:
class emp { int age;
void birthday() { age++; };
};
and to create an employee instance we might do:
emp e;
then the applying of a birthday would be:
e.birthday();
However in C we would have to write:
struct emp { int age; };
void birthday( emp *e) { e->age++;};
and to create an instance we might do:
emp e;
then the applying of a birthday would be:
birthday(&e);
This may seem subtle at first, but the change is one from interacting
with objects to passing data structures to functions or procedures.
Firstly, expressiveness is lost. It is easier to express solutions to many problems using an object language rather than in traditional languages. In general, those who have used object-oriented languages extensively find procedural languages harder work, and less easy to read. Object-oriented languages are arguably more elegant than there procedural counterparts, and elegance more often than not leads to better designs.
Then there is a loss of convenience. If you have an object design, it is much easier to write down the object model directly using the objects in an object-oriented language.
Object-oriented languages support encapsulation. The only way to modify data is through legally permitted operations on an object. This reduces the likelihood of errors through inappropriate access to data (the advantages of this in C++ are reduced because of the poor memory protection in C and C++). It also should enhance maintainability.
But perhaps the most important loss in using non-object implementations is the loss of coherence between analysis, design and implementation. Object-oriented methods offer, for the first time in software design, a coherent and consistent notation from requirements analysis through to system implementation. The benefits of this are considerable, in terms of ease of analysis, design, implementation and maintenance. They are already having payoffs in the production of CASE tools which support more of the software development process.