I have some serious issues understanding PHP class
from a book. It seems so difficult. I guess I am more of a visual learner. Can anyone recommend me a great resource to help me learn this better?
views:
275answers:
5This is really good for the beginners:
Object Oriented PHP for Beginners
Those are the visual tutorials.
http://www.spoono.com/php/tutorials/tutorial.php?id=27
This got me started, it's a good introduction.
I know you asked for a resource, not an explanation, but here's something by what I understood basic implementation of classes:
Imagine class as a template of building. A basic sketch how a building should look like. When you are going to actually build it, you change some things so it looks like your client wants (properties in case of class). Now you have to design how things inside of the building are going to behave (methods). I'm going to show it on a simple example.
Building class:
/**
* Constructs a building.
*/
class Building
{
private $name;
private $height;
public function __construct( $name, $height )
{
$this->name = $name;
$this->height = $height;
}
/**
* Returns name of building.
*
* @return string
*/
public function getName( )
{
return $this->name;
}
public function elevatorUp( )
{
// Implementation
}
public function elevatorDown( )
{
// Implementation
}
public function lockDoor( )
{
// Implementation
}
}
Calling the class:
// Empire State Building
$empireStateBuilding = new Building( "Empire State Building", 381 );
echo $empireStateBuilding->getName( );
$empireStateBuilding->lockDoor( );
// Burj Khalifa
$burjKhalifa = new Building( "Burj Khalifa", 828 );
echo $burjKhalifa->getName( );
$burjKhalifa->lockDoor( );
Just copy it, run it on your localhost and try to do some changes. In case of any questions, just ask me. If you don't find this useful, just use links of previous posters, those are pretty solid tutorials.
In a nutshell, a Class encapsulates conceptually related State and Responsibility of something in your Application and usually offers an programming interface with which to interact with these. This fosters code reuse and improves maintainability.
Imagine a Lock:
class Lock
{
private $isLocked = false;
public function unlock()
{
$this->isLocked = false;
echo 'You unlocked the Lock';
}
public function lock()
{
$this->isLocked = true;
echo 'You locked the Lock';
}
public function isLocked()
{
return $this->isLocked;
}
}
Ignore the private
and public
declaration right now.
The Lock class is a blueprint for all the Locks in your application. A Lock can either be locked or unlocked, represented by the property $isLocked
. Since it can have only these two states, I use a Boolean (true
or false
) to indicate which state applies. I can interact with the Lock through it's methods lock
and unlock
, which will change the state accordingly. The isLocked
method will give me the current state of the Lock. Now, when you create an object from this blueprint, it will encapsulate unique state, e.g.
$aLock = new Lock; // Create object from the class blueprint
$aLock->unlock(); // You unlocked the Lock
$aLock->lock(); // You locked the Lock
Let's create another lock, also encapsulating it's own state
$anotherLock = new Lock;
$anotherLock->unlock(); // You unlocked the Lock
but because each object encapsulates it's own state, the first lock stays locked
var_dump( $aLock->isLocked() ); // gives Boolean true
var_dump( $anotherLock->isLocked() ); // gives Boolean false
Now the entire reponsibility of keeping a Lock either locked or unlocked is encaspulated within the Lock class. You don't have to rebuilt it each time you want to lock something and if you want to change how a Lock works you can change this in the blueprint of Lock instead of all the classes having a Lock, e.g. a Door:
class Door
{
private $lock;
private $connectsTo;
public function __construct(Lock $lock)
{
$this->lock = $lock;
$this->connectsTo = 'bedroom';
}
public function open()
{
if($this->lock->isLocked()) {
echo 'Cannot open Door. It is locked.';
} else {
echo 'You opened the Door connecting to: ', $this->connectsTo;
}
}
}
Now when you create a Door object you can assign a Lock object to it. Since the Lock object handles all the responsibility of whether something is locked or unlocked, the Door does not have to care about this. In fact any objects that can use a Lock would not have to care, for instance a Chest
class Chest
{
private $lock;
private $loot;
public function __construct(Lock $lock)
{
$this->lock = $lock;
$this->loot = 'Tons of Pieces of Eight';
}
public function getLoot()
{
if($this->lock->isLocked()) {
echo 'Cannot get Loot. The chest is locked.';
} else {
echo 'You looted the chest and got:', $this->loot;
}
}
}
As you can see, the reponsibility of the Chest is different from that of a door. A chest contains loot, while a door separates rooms. You could code the locked or unlocked state into both classes, but with a separate Lock class, you don't have to and can reuse the Lock.
$doorLock = new Lock;
$myDoor = new Door($doorLock);
$chestLock = new Lock;
$myChest new Chest($chestLock);
Chest and Door now have their unique locks. If the lock was a magical lock that can exist in multiple places at the same time, like in Quantum physics, you could assign the same lock to both chest and door, e.g.
$quantumLock = new Lock;
$myDoor = new Door($quantumLock);
$myChest new Chest($quantumLock);
and when you unlock()
the $quantumLock
, both Door and Chest would be unlocked.
While I admit Quantum Locks are a bad example, it illustrates the concept of sharing of objects instead of rebuilding state and responsibility all over the place. A real world example could be a database object that you pass to classes using the database.
Note that the examples above do not show how to get to the Lock of a Chest or a Door to use the lock()
and unlock()
methods. I leave this as an exercise for your to work out (or someone else to add).
For some resources check
To offer a view from another angle if I may please (based on personal experience). You need to feel "the need of OOP" before you can actually understand what is it all about - IMHO, learning resources should come after this.
One would basically "need" to be stuck in structural difficulties when writing relatively large piece of software written in procedural style (as opposed to Object Oriented, sorry if anyone disagree with the term). By then, he/she could try restructuring the code into objects to better organize it and, naturally, learn more about OOP in detail. Again, this is my personal experience and it brought me into understanding faster than any book.
Just my two cents.