Going OO
elyob
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.
Thanks
Dikkie Dik
> 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.
elyob
"Dikkie Dik" <nos...@nospam.org> wrote in message
news:7e0ec$441c18e3$57d40752$12...@news.versatel.nl...
>> 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.
>
> 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.
Thanks for the advice. Some useful ideas in there. Now I guess I need to
just get my head around the physical language.
So, if I was building a cart from scratch I'd think ....
session handler
opendatabase
displaycart
addtocart
displayshop
Then I'd need to start building it. Is this stage 1? Is this how you'd think
it out?
Dikkie Dik
> Thanks for the advice. Some useful ideas in there. Now I guess I need to
> just get my head around the physical language.
>
> So, if I was building a cart from scratch I'd think ....
>
> session handler
> opendatabase
> displaycart
> addtocart
> displayshop
>
> Then I'd need to start building it. Is this stage 1? Is this how you'd think
> it out?
>
"actions". The actions on the objects are its methods. So you could have
a Shop object and a ShoppingCart object, for example. The Shop object
would probable have a ShoppingCart inside, so if you would give the command
$objShop->display();
the shop object itself would probably call $objShoppingCart->display()
as a part of that action.
Due to the stateless way web servers work, the ShoppingCart must be
"refreshed" from the session and/or the database at every page buildup.
This initializing code can be put in the constructor. If you would
decide to use separate objects for the session or the database, you
could pass them as arguments to the constructor.
So an adding to a cart could look like:
$objShoppingCart = new ShoppingCart($_SESSION, $dbs);
$objShoppingCart->add(....);
In the class ShoppingCart, there would be functions
public function __construct($session_array, $database)
{ // code to read items from the session and the database
}
public function add(....)
{ // code to add an item to the shopping cart.
}
public function display()
{ // code to display the contents.
}
Have fun.
LaieTechie
In my first OOP course, the instructor told us that objects are black
boxes with attributes (properties) and actions (methods). Objects are
categorized into classes. All objects of the same class have the same
attributes (maybe different _values_, though) and the same actions.
A class may have a super class and / or some sub classes. Super classes
are more general ("abstract") and sub classes are more specific
("concrete"). This inheritance pattern is general described with an "is
a" phrase. A Malibu is a Car. A Car is a Vehicle.
Besides inheritance, you can aggregate objects together. This is
described with "has a". A Car has an Engine. When you tell a Car to
"turn on" it delegates that command to its Engine.
The whole point of using objects and classes is abstraction. You program
to a certain interface ("API") without having to worry about the specifics
of how it gets its job done.
HTH,
Laie Techie