Limitations of Procedural-Oriented Programming
Limitations of Procedural-Oriented Programming
-
Well, although procedural-oriented programs are extremely powerful, they
do have some limitations.
-
Perhaps the most serious limitation is the tendency for large procedural-based
programs to turn into "spaghetti-code".
-
Spaghetti code is code that has been modified so many times that the logical
flow shown in the figures above becomes so convoluted that any new programmer
coming onto the project needs a two month prep-course in order to even
begin to understand the software innards.
-
Why does this happen?
-
Well, in reality, a programmer's job has just begun when she finishes writing
version 1.0 of her software application. Before she knows it, she'll be
bombarded with dozens of modification requests and bug reports as users
actually get to batter and bruise her poor piece of code.
-
In order to meet the demands of the evil user, the programmer is forced
to modify the code. This can mean introducing new sub loops, new eddies
of flow control and new methods, libraries and variables altogether.
-
Unfortunately, there are no great tools for abstraction and modularization
in procedural languages...thus, it is hard to add new functionality or
change the work flow without going back and modifying all other parts of
the program.
-
Now, instead of redesigning the workflow and starting from scratch, most
programmers, under intense time restrictions will introduce hacks to fix
the code.
-
This gets us to the second problem with procedural-based programming. Not
only does procedural code have a tendency to be difficult to understand,
as it evolves, it becomes even harder to understand, and thus, harder to
modify.
-
Since everything is tied to everything else, nothing is independent. If
you change one bit of code in a procedural-based program, it is likely
that you will break three other pieces in some other section that might
be stored in some remote library file you'd forgotten all about.
-
A final problem with spaghetification, is that the code you write today
will not help you write the code you have to write tomorrow. Procedural-based
code has a tenacious ability to resist being cut and pasted from one application
to another. Thus, procedural programmers often find themselves reinventing
the wheel on every new project.
Procedural-oriented programming is actually very
powerful, so don't let the hype make you think that it has no place in
your arsenal of programming tools.
Like libraries, languages, and toolkits, methodologies are just ways
to solve certain sets of programming problems. There is no such thing as
an all - powerful methodology. In some cases, the object-oriented approach
will be best suited to your needs and in others, another methodology might
be more appropriate.
PS: A well written procedural-oriented program can actually be easy
to understand. It is just that well written procedural code is hard to
find, especially when 'teams' of programmers, working on multiple versions
are involved. The fact is that procedural languages typically lack the
syntactic sugar necessary to enforce abstraction |
Procedural
Programming
Table of Contents
Object-Oriented Programming
|