In a nutshell, a Class is a blueprint for an object. And an object 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:
namespace MyExample;
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 namespace, 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 (also often referred to as an instance) 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/instance 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).
Also check When to use self over $this? for a more in-depth explanation of Classes and Objects and how to work with them
For some additional resources check