Many years ago I wrote something for newcomers into OOP. I have cut a
snippet out of it and added some comments. Sorry, it became rather long.
Hope it helps somebody.
Frank
"
OOP is the art of designing "objects", then creating and killing them. An
object is a box with handles. We can operate it without disturbing anything
else. We can make them and kill them as needed.
When the first radios were designed they were very spaghetty. Though the
designer had a idea of what modules he needed he'd freely with a lot of
wires interlink all over the place, simply because it was the easiest and
fastest thing to do. And the radio was made and worked fine.
The drawbacks: Not a single piece of work could be used in another radio
unless the engineer would enjoy sorting out all the possible wires and what
could happen in any part of the radio. And getting help was hard unless the
helper was interested in understanding the entire construction. He could
not disconnect any particular part of the radio and test it alone.
Independent modules were the answer. The engineer had always had these in
mind conceptually - but in his work they just happened to get mixed up with
wires and as complexity grew the benefit of soldering the little extra wire
from A to B were later outweighted by the costs above. So increasingly the
development grew towards small units with well-defined input and output
which dramatically changed the entire industry. Suddenly high complexity
could be made in a module which could then be sold to many different
manufacturers of radios.
Programming had exactly the same problems. Though programmers were well
aware - and did it well - of the importance of making modules something
were missing. The ability of creating modules that could be designed so
their state, data and functions existed isolated from everything else.
Another problem: a customer once ordered a little program where he on the
screen could build up a page for printing. I made it, it worked fine - and
then he said "It would be great if I could have two pages at the same time
and swap between them." Hmm. Instead of just using nLines to hold the
numbers of lines of the printed page I now had to use nLines1 and nLines2.
I was smart enough to make the nLines and other variable into an array
nLines[1..nPages] if he should get ideas of more pages. I proudly went back
to him and say "Now you can decide on your own maximum of pages needed!"
Great, but would I always in the future have to use arrays instead of
simple variables if somebody had the need for more "something" at the same
time? I tried that. The cost was more clumsy code, slower to write and
execute - and most often only one instance was ever needed.
OOP had answer to all of this. Modules that can't be touched, which exist
by themselves. You could really get a module from somebody else and put it
right into your program. The module could be full of variables that had the
same names as yours. "i, pageLength, sum". While earlier we'd have to
carefully prefix variables with something to make sure they didn't clash
this problem was gone as the variables only existed inside the module.
The printer-page application of above - now I wouldn't have to sit and
decide whether to use arrays or simple variables. I'd simply write the
description of how this printer-page worked (called a "class") and then I
could make and kill as many of them as I needed.
class MyPrintpage
{
variables...
functions...
}
This class didn't "make a page" like the old code would have done. It just
described _how_ to make it. And it didn't take one bit more time to write
than in the old style. To actually "create" a page we could use we wrote
MyPrintpage p1;
If we one day needed two we'd write
MyPrintpage p1, p2;
And when we didn't need it anymore we would write
delete p2;
and the memory was freed. An amazing difference!
"
(End of snippet of old article.)
OOP seems to me to be in everyday programming to be a little less natural
to use in PHP because of the short lifetime of the script.
Imagining Windows applications programming without ability to create and
destroy objects is flatly impossible in praxis.
But PHP-scripts for web-pages tends to deal with one-shot functionality
from a single input. Rarely much is build (though that wouldn't necessarily
have to be so.) Accessing a MySQL database and fetching rows does not call
for objects. Etc.
In other words - OOP is not immediately pressing its way in as a necessary
concept. When I did C++ I only did OOP - in PHP rarely.
That is not to say that OOP is not of value in PHP. It very much is and
many valuable classes have been designed where old-style design would have
been senseless.
It's just, well, maybe not something that the ordinary web-programmer will
benefit much from at the beginning. No need to feel that you are missing
out on something smart you should have done instead.
I haven't checked the code in details, but I wonder if excellent PHP tools
like PHPmyAdmin, Phorum etc. is using OOP at all?
Learn OOP along the way. But maybe focus on good style etc. etc. in the
beginning.
My 0.02$
Frank
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
