OOP is not really about how a single class looks and operates. It's about how instances of one or more classes work together.
That's why you see so many examples based on "Cars" and "People" because they actually do a really good job of illustrating this principle.
In my opinion, the most important lessons in OOP are encapsulation and polymorphism.
Encapsulation: Coupling data and the logic that uses that data together in a concise, logical manner
Polymorphism: The ability for one object to look-like and/or behave-like another.
A good real-world example of this would be something like a directory iterator. Where is this directory? Maybe it's a local folder, maybe it's remote like an FTP server. Who knows!
This is encapsulation:
abstract class DirectoryIterator
{
protected $root;
public function __construct( $root )
{
$this->root = $root;
}
abstract public function getAll();
}
class LocalDirectoryIterator extends DirectoryIterator
{
public function getAll()
{
// logic to get the current directory nodes and return them
}
}
class FtpDirectoryIterator extends DirectoryIterator
{
public function getAll()
{
// logic to get the current directory nodes and return them
}
}
Each class/object is responsible for its own method of retrieving a directory listing. The data (variables) are coupled to the logic (class functions i.e, methods) that use the dta.
But the story is not over - remember how I said OOP is about how instances of classes work together, and not any single class or object?
Ok, so lets do something with this data - print it to the screen? Sure. But how? HTML? Plain-text? RSS? Let's address that.
<?php
abstract class DirectoryRenderer
{
protected $iterator;
public function __construct( DirectoryIterator $iterator )
{
$this->iterator = $iterator;
}
public function render()
{
$dirs = $this->iterator->getAll();
foreach ( $dirs as $dir )
{
$this->renderDirectory( $dir );
}
}
abstract protected function renderDirectory( $directory );
}
class PlainTextDirectoryRenderer extends DirectoryRenderer
{
protected function renderDirectory( $directory )
{
echo $directory, "\n";
}
}
class HtmlDirectoryRenderer extends DirectoryRenderer
{
protected function renderDirectory( $directory )
{
echo $directory, "<br>";
}
}
Ok, now we have a couple class trees for traversing and rendering directory lists. How do we use them?
// Print a remote directory as HTML
$data = new HtmlDirectoryRenderer( new FtpDirectoryIterator( 'ftp://example.com/path' ) );
$data->render();
// Print a local directory a plain text
$data = new PlainTextDirectoryRenderer( new LocalDirectoryIterator( '/home/pbailey' ) );
$data->render();
Now, I know what you're thinking, "But Peter, I don't need these big class trees to do this!" but if you think that then you're missing the point, much like I suspect you have been with "Car" and "People" examples. Don't focus on the minutiae of the example - instead try to understand what's happening here.
We've created two class trees where one (DirectoryRenderer) uses the other (DirectoryIterator) in an expected way - this is often referred to as a contract. An instance of DirectoryRenderer doesn't care which type of instance of DirectoryIterator it receives, nor do instances of DirectoryIterator care about how their being rendered.
Why? Because we've designed them that way. They just plug into eachother and work. This is OOP in action.