Differences Between Procedural and Object Oriented

March 4, 1999 - Jack Harich - At a JSL Meeting with input from many - Go Back

Here are the differences for various elements. We are skipping the definition of Procedural and Object Oriented, which is usually defined as what their basic unit and core features are. The core features of OO are, in order of importance, encapsulation, polymorphism and inheritance. Note that in a few situations procedural is preferred, such as for scripts, embedded systems with small memory requirements and very high speed.

Once you have digested Object Oriented, the next level of abstraction is Ultra High Reuse where we first become Part Oriented, aka Part Centric.

Note that a procedural language such as C can be used in an Object Oriented style. The problems are that some aspects such as inheritance, polymorphism and instances are harder to achieve. A rigorous coding standard is required. The literature has commented several times that achieving OO in a procedural language using an OO style is terribly hard for a group to adopt.

Element

Procedural

Object Oriented

Basic unit is defining characteristic Algorithm, code is all how to do it Object, an encapsulated abstraction
Design focus How its done Responsibility allocation
Major artifact Usually none, sometimes Flow Chart Various Models, especially Object Model
File size Large, I heard of a 10,000 line file Small, my goal is 200 lines max
Real world counterpart A letter with instructions on what to do Entity who responds to requests
Scalability Medium Infinitely high
Performance High Medium
Engine complexity Medium High
Model size Larger Smaller
Richness of design artifacts (models) Low High
Ease of learning Easier Harder, unless no procedural habits
Ease of reuse Very low unless table driven High
Ease of maintenance (defect fixes) Low High if good design
Ease of extensibility Medium High
Ease of tiny system High, especially scripting languages Low
Ease of distributed system Low High
Ease of Artificial Intelligence Impossible Medium for average OO language
Ease of Unit Testing Low unless designed for it High especially if designed for it
Appropriate for event driven system Low High
Modularity Low due to large files, tight coupling High
Encapsulation Tends to be low, can be high Much easier
Appropriateness for CPU bound algorithm High, since procedural is algorithm oriented Low until a miracle occurs
Ease of understanding, self documenting Low, gotta chase a method call to find out what it is doing High since all you have to know is the interface and understand the model. Inheritance also makes understanding what methods are available easier.
Data complexity handling Anything can be done But is easier here!
Variable list explosion Can easily happen Tends to rarely happen
Development efficiency Average, falls off with system size With training, big improvement. Without training, worse than procedural.

How to tell if you are thinking OO and not procedural

It's normal to still design and code in a procedural style when you move up to an OO language such as Java. Here's a list of the signals that can tell you if you are truly thinking OO yet:

In OO lots of preparation proceeds coding. Check this one first! You can spend lots of time designing procedural, but what usually happens is folks dive right into coding if they have a procedural mindset. They are often encouraged to do this by peers and mangers, as the following from a JSL member shows:

True story time. In 1974 at a shop using PDP8 assembler, a programmer was given a project but needed to first study a large manual to figure out what to do. He went to his office and had barely sat down when his manager stuck his head in the door and said, "Don't think about it. Do it!"

In OO your classes tend to be small. My goal is 200 lines max 90% of the time. One of your biggest problems when first moving from procedural may be huge classes.

In OO your classes tend to have simple, singular responsiblities. Remember, a good class does one thing and does it well.

In OO arguments are frequently objects. In mature work you are probably passing more objects than primatives.

In OO objects are frequently passed a long way, ie from instance to instance to instance.

In OO polymorphism (interfaces, some subclassing) is used a lot. It may be the backbone of your architecture.

In OO inheritance is used moderately. More appropriate is composition.

In OO you are thinking more about how classes interact than how to code.

In OO development is architecture driven.

You don't have VB on your computer and you think COBOL is a shade of blue. :-)

In OO the appearance of class roles just happens. Examples are factories, datatron, mediator.

In OO high reuse is one of your goals.

In OO you tend to have suprisingly short methods. The average in Smalltalk is 6 lines.

In OO you always model before coding.

In OO you open your modeling tool before your editor most of the time.

In OO the amount of time you spend coding is dramatically less. Statistics for mature OO shops are 1/3 in analysis, 1/3 in design, 1/6 in coding and 1/6 in testing. For procedural the statistics are 1/3 in analysis and design, 1/3 in coding and 1/3 in testing. Amazing!

OO systems tend to be well organized, but procedural systems often end up as bird's nest code.

In OO you capture lots of abstractions, allowing the system to closely represent the real world.

Good luck!