|
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
work flow 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.
|
|
Greg Smith sent in the following excellent comments...
It was good to see "Limitations of Procedural-Oriented Programming" but
spagetti is the result of goto'ing all over the place ("goto"ing,
"exit"ing, "leave"ing, "break"ing etc.). The single strand / thread, of
control, whatever, is lost.
Programs written without the abortions of logic can be read, understood,
debugged, etc. in half the time. (a paper witten back in the 60's was the
first recognition of the problem and it outlined the new "structured"
approach which from then on has been the known preffered method).
Again,
OOP can offer almost the same benefit on top of that . . . if still, the
rules of structure, are followed, and not the spagetti of goto's, etc.
Unfortunately, all languages still support most, if not all, of the options
for making spagetti out of what could have been structured code. just as
C++ offers the ability to use OOP methods, but does not require it.
(in C the case statement seems to be written so as to nearly require
"break"ing)
F I R S T
------------------------------------
THE 3 BASIC PROGRAMMING CONSTRUCTS:
------------------------------------
1. SEQUENCE consegutive
2. BRANCH if - else
3. LOOP do while
------------------------------------
Basics of structured programming:
- there are no goto's, jumps, iterates, etc.
- all loops terminate at the bottom.
((the condition may be at the top))
- there are no infinite loops.
Structured code is easier to write, debug,
and maintain than the "spagetti" world of
goto's, iterates, and exits that preceeded.
Once it was discovered, in the early 60's,
that the time involved in programming could
be cut in half by following the rules given
above, there has been no defensible
justification for doing otherwise, though
"spagetti" persists.
S E C O N D - OOP
------------------------------------
Object Oriented Programming
is a methodology that gives great importnace
to relationships between objects rather than
implementation details. This distinction is
important and like Structure above, can make
code easier to write and maintain.
|
|
