The secret of the leap from using objects to Object Oriented programming
Once upon a time there was an object.
He was very lonely, because noone used him.
His name was DB_DataObject.
He was a parent of DO_Client, and DO_Address.
His first adventure looked more or less like that:
<?php
// All the includes go in here
// Adventure one - updating Client's name and his address' postcode:
$Client = DB_DataObject::factory('client');
$Client -> get(1);
$Client -> name = “My name is Earl”;
$Client -> update();
$Address = DB_DataObject::factory('address');
if ($Client->address_id) {
$Address -> get($Client->address_id);
}
$Address -> postcode = “ME16 8LB”;
if ($Client->address_id) {
$Address -> update();
} else {
$Address->insert();
}
// Adventure two: Finding Client's full address
$Client = DB_DataObject::factory('client');
$Client -> get(1);
$Address = DB_DataObject::factory('address');
$Address -> get(Client->address_id);
$strAddress = $Address->line1 .”\n” . $Address->line2 . “\n” . $Address->postcode;
?>
While the code above isn't bad enough to criticize it - it doesn't use the Object Oriented paradigm at all - it uses objects, but isn't Object Oriented.
It doesn't abstract the behaviour of the objects and doesn't allow you to access them independently of their implementation.
For example - you shouldn't really care if the address exists or not, if the only thing you want is to edit the postcode - if there's no address - why shouldn't the object create an appropriate container for you?
After refactoring into proper Object model, the same code as above could look like:
<?php
// Adventure one - updating Client's name and his address' postcode:
$Client = new Client(1);
$Client -> setName ("My name is Earl");
$Client -> store();
$Client->getAddress()->setPostcode("ME16 8LB");
$Client->getAddress->store();// Adventure two: Finding Client's full address
$Client = new Client(1);
$strAddress = $Client->getAddress()->toString();
?>Isn't that quicker and cleaner?
Obviously the code we had in the first example won't disappear, it will be simply moved to a lower layer, but the fact of doing it - allows us to use it in another places without re-writing it. And avoiding re-writing is the most important principle of effective programming.
Your homework is to create the code for the Address and Client classes and see if you can feel the difference 
Oops, I almost forgot - the secred.
Anything the customer tells you - you write it first in Objects and Methods (e.g. Customer->createNewOrder->setOrderDate) and you start implementing your code from there.
After some time you'll discover that your implementation isn't perfect, but that's time to learn about refactoring, and more importantly - the Design Patterns.
As I say, this isn't all there is to Object Oriented programming, but the leap you need to execute in order to be able to claim your programming is truly Object Oriented consists of nothing more than from abstraction, abstraction and abstraction - all done by using Classes and Methods.
One important thing - static classes, or methods called statically won't help you make the leap, so try everything you can to avoid them in the early stages of your work.