Posted by Dikkie Dik on 03/18/06 16:27

> I've always been a procedual coder, and am looking to get into OO asap. Any
> hints and tips appreciated, I've not totally got my head around it yet.

Great! I have to give a few workshops on programming, so I am going to
use you as my first victim...

So let me start with the question: What is an object?

An object is a piece of a program. But is a piece of a program with a (
usually elementary) task. If you open a modern video recorder, you'll
see subassemblies with a specific task: the power source, the motor
control, the button panel, the video signal processor unit, the audio
amplifiers, etc. If you buy a different video recorder from the same
factory, you will notice that some of the subassemblies are the same:
They are REUSABLE. They can only be reusable when they do only their
specific task and do not interfere with other tasks.

By plugging all the subassemblies together, you get the videorecorder

Like the subassemblies in the videorecorder, an object has an inside, an
outside and a border between them. What happens inside the object is the
responsibility of the object itself, and not of any interest to you,
unless you have to build it or repair it. It is of no interest whether
an ErrorMailer object holds code or a little imp with a laptop and an
internet connection. The interesting thing is that you can use it to
send an error condition by e-mail.
The outside world can only communicate with an object through its
INTERFACE. This interface is formed by all available pieces of it (don't
confuse it with the interface keyword in PHP5). This also means their is
a public interface (all publicly available parts, available to
outsiders), a protected interface (all "protected" and public parts,
available to subclasses) and a private interface(all parts, available
from within the object). This interface can be seen as a plug. An
amplifier subassembly has three plugs: a power connection, an input plug
and an output plug. Together, they form the interface of an amplifier.

Is this not extra work? Well, it is in lines of code. initially. But it
is not in your head. If you know which components work, you can
concentrate on the component that does not. In the procedural style, the
whole program could interfere. Thank goodness we did something about
that. Furthermore, because knowledge of the interface is enough to drive
an object, you can test it separately. With a little test bench that is
called a UNIT TEST.
It may be a lot less work if you realize that you can leave the actual
building of an object to somebody else if you define its interface. IBM
has defined a hardware interface for personal computers, but most
personal computer hardware is built by other factories. Compliant with
IBM's interfaces, off course. Otherwise, it would not work. In PHP, you
can leave e-mail sending to a PHPMailer object, for example.

All this requires a different thinking. In the procedural style of
programming, if you needed something from a storage, you just went and
got it. Usually without any control. If the stuff you were looking for
was not there, you could take alternative actions (looking in different
places, building things yourself, etc.). In object-oriented style, you
just ask a WareHouseMan object to give it to you. Any alternative
actions are now the responsibility of the WareHouseMan object, not
yours. It is also the responsibility of the WareHouseMan to keep an eye
on how many things there are, and how many there are needed in the
store. This also gives the WareHouseMan object the unique opportunity to
optimize his own business. As long as he does what is asked from him.
Oh, the WareHouseMan might delegate his responsibilities, off course, to
a Collection for the actual storage, an ItemBuilder to build a new item
that is asked for, but not in storage, etc.

So what happens if you keep on doing the procedural style of
programming, and just put a class statement around it? You will end up
with a huge class that is hard to maintain, hard to optimize and hard to
find a bug in. And almost impossible to test. This is called a "Blob" or
a "God class".

What happens if you use global variables? You then actually "hardwire"
your objects that use the global variable to the outside world. This has
major consequences: The object is not a separate entity anymore, so
cannot be tested, repaired or replaced separately anymore. Furthermore,
the outside world now "leaks in" into the object, so the object can no
longer hold his own responsibility for his own task.

An example. Let us say you want to list the products in some category on
your site.

Procedural style:
-Open a database connection
-Build some SQL query
-Pass that to the database
-No errors? Not an empty set? then echo the start of the list
-While not completed, get each row from the results
-build a result string from it
-echo it to the webbrowser
-close the connection
-Did I write the start of a list? then echo the end also.

Object oriented style:
$objList = $objProducts->GetSelectionListByCategory($category);
$objHtmlList = new HtmlList($objList);
echo $objHtmlList->ToHtml();

You see, how the products collection gets the list is his problem. It
was probably initialized with a database connection, and it might even
delegate all database handling to a separate class (recommended). The
thing is, the Products collection only has to worry about products, and
the HtmlList only has to worry about generating HTML from a list (which
is probably a collection or an array).


Let me end with one word of advice. Object oriented thinking and
designing does not come in one day. Start with program parts you can
"feel" that they should be an object, and define classes for them.
Having a PHP page with still much procedural code and also some calls to
objects is much better then to just put a class keyword around a lot of
procedural code.
Do not be afraid that your design is not optimal. It probably isn't. And
if it is now, it will not stay that way, as the outside world of it
changes and objects too have to adapt. A less than optimal design is not
bad, because you learn from it, and because it forms the basis of a
better design.

Good luck.

[Back to original message]