Select Page

This article discusses an Object-Oriented (OO) approach, by describing what are the alternatives, and what came before.

There are different ways to organize and represent a problem or system in code.  OO is a different paradigm from organizing the concepts in a domain than through modular programming, functional decomposition or data modeling, and understanding how it is different, is key to understanding object-orientation.

Writing small programs is easy.  Writing large programs is very hard.  The computing problem is one of scale.  In principle the solution is fairly straightforward, break big programs into smaller pieces that can be constructed independently and then combined.  How to do that better remains the biggest challenge in computing.

Modular Programming

One can represent a problem or system in a number of lines of code, or instructions, called a procedure.  The introduction of the subroutine in the 1950’s revolutionized the ability to organize large problems represented by huge procedures (lines of code). However, by the end of the 1950’s, modular programming based on procedures and subroutines had become problematic. It was hard to have large teams of programmers working on parts of the code at the same time, and it was hard to create large well-structured programs.

Functional Decomposition

The answer in the 1960’s was to break down a problem into pieces, then sub-components, then subroutines through functional decomposition. This better allowed large problems to be understood, and worked on by different teams at the same time.

This approach has resulted in quality software over the years, but suffers from painful limitations. One of the big ones is that as one works on a problem and discovers its requirements, the decomposition used needs to be modified, often from the top down.


Object-orientation represents a different way to approach a problem. Let’s break down a large problem or system into entirely independent concepts that know how to to do things themselves. Let’s NOT orchestrate these concepts (objects) centrally, but instead have them do things themselves together to solve a problem.

This comes close to the way we think. We recognize and organize things in our minds around us as objects. We differentiate between them by their attributes, and we classify them. When we see a tree we recognize it as such, and differentiate it from other by its attributes and also by its place in the hierarchy of types of trees we know. Behavior on the other hand is only immediately important to us if it is causal – for example if it threatens us. That unknown thing moving fast towards you prompts immediate changes in your body and action, but once you recognize the object is a beetle and not a spider, you can respond more appropriately.

Note: Information Modeling described in the Data Modeling section below, also bases its concept of entities, on objects abstract or real.  Due to this, it also has an advantage in mapping well to the way we think.

Hopefully, this also makes the point that the term object can be ambiguous and confusing, because it is used in both object-orientation and in Information Modeling to represent subtly different things.

Data Modeling

The approaches described above have focused on representing problems or systems in terms of logic.  An alternative is to model the world in data through an Information Modeling, or a Data Flow approach (Structured Analysis).

Information Modeling is probably better known through its main modeling tool – the entity-relationship diagram, and to some as semantic data modeling.  There are two strategies used to apply real world systems in this approach.  Interestingly, the more modern one prescribes finding objects in the real world and describing their attributes, before adding relationships, refining super/subtypes, associative objects and then normalizing.  This approach has the advantage of being based on the amazing technology and theory of modern relational database systems.

A Data Flow (Structured Analysis) approach represents a problem or system by establishing the flows that transform data.  Numerous issues have lead to this approach largely disappearing as a way to represent a complex problem or domain based systems.  Going into that is outside the scope of this article, but I will revisit it another time, because it is interesting to look at this approach in light of the increasing popularity of functional languages and programming.

Structured Programming in Object-Oriented Languages

Functional decomposition and Information Modeling remain the most common way to organize and write code today, even when using object-oriented languages, where the “object” is commonly used as a container to store data, as a modular namespace for a group of related functions, or a combination of both.

Using structural features of OO languages like objects, late binding and classes, or merely adding a method to an object, does not make for an object-oriented solution or system.  (see Structured-Objects approach)

Data modeling still largely remains the way problems and systems are modeled and represented in business, commerce and industry.  The data modeling concept of entities representing real world objects, maps well to objects in an object-oriented language.

A Data Modeling Example using Objects

Perhaps I can close with an example that might help illustrate aspects of objects, data modeling and object-orientation.

Microsoft architectures have traditionally been based on representing problems and systems using a data modeling approach.  Their product Entity Framework, continues this emphasis today.  They would represent concepts of the data model as objects like DataSet, DataTable, DataRow etc.  One would typically then have logic and constraints in procedures [1] that mapped to an action or use case, that in turn manipulated these data objects within a transaction.  This approach maps particularly well to a tools based approach which supports the automatic generation of data objects, and even the user interface.

My point is that using this architecture does mean that you are coding using objects, most likely within an object-oriented language.  You may use aspects of the language like polymorphism, objects, encapsulation, classes, state retention, object identity etc, but it is using a data modeling approach to the problem or system, NOT an object-oriented one.  The objects in this case are representing data entities, not concepts within an object-oriented approach.

Hopefully, I’ve at least provoked the thought that object-orientation is not about how you use language features, but about how you represent and organize a complex problem or system in code.

[1] Some might refer to these also as controllers, managers, supervisors or service layer objects.

See Also

Share This