Going OO

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Kimmo Laine wrote:
Quoted text here. Click to load it

Unless next_page.php generates PHP, the script with this include will
only get HTML.

Quoted text here. Click to load it


    if (isset($_GET['foo'])) {
      echo '<?php echo $_GET[\'foo\']; ?>';
    } else {
      echo '<?php echo \'Not available\'; ?>';

File not found: (R)esume, (R)etry, (R)erun, (R)eturn, (R)eboot

Re: Going OO

Quoted text here. Click to load it

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.

Re: Going OO

Quoted text here. Click to load it

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

Then I'd need to start building it. Is this stage 1? Is this how you'd think  
it out?

Re: Going OO

Quoted text here. Click to load it
Well, it's a good start, although objects tend to be more "things" than  
"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
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);

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.

Re: Going OO

On Sat, 18 Mar 2006 12:34:01 +0000, elyob wrote:

Quoted text here. Click to load it

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.

Laie Techie

Site Timeline