OOP: A Bird's Eye View

[Arunbear]

Most tutorials that teach Perl OOP (Object Oriented Programming) focus on the nuts and bolts (which is important), but neglect the equally important "Why" or reasons for using OOP. This is an attempt to remedy that, in the form of a story.

A fable

There once was a farmer who had a flock of sheep. His typical workday looked like this:

$farmer->move_flock($pasture);
$farmer->monitor_flock();
$farmer->move_flock($home);

Eventually, due to successful wool sales, he expanded his farming activities and his day become like this:

$farmer->move_flock($pasture);
$farmer->monitor_flock();
$farmer->move_flock($home);

$farmer->other_important_work();

But now the farmer wanted to devote more time to other_important_work(), so he decided to hire a minion to handle the sheep related work, so the work was now split like this:

$shepherd_boy->move_flock($pasture);
$shepherd_boy->monitor_flock();
$shepherd_boy->move_flock($home);
 
$farmer->other_important_work();

This did give the farmer more time for other_important_work(), but unfortunately $shepherd_boy had a tendency to cry wolf so the farmer had to replace him with a new minion:

$sheep_dog->move_flock($pasture);
$sheep_dog->monitor_flock();
$sheep_dog->move_flock($home);
 
$farmer->other_important_work();

$sheep_dog was more reliable and demanded less pay than $shepherd_boy, so this was a win for the farmer.

Ideas

Delegation

To handle complexity, delegate to a suitable entity e.g. the farmer delegates some of his work to $shepherd_boy.

Encapsulation

Tell objects what to do, rather than micro-manage e.g.

$sheep_dog->monitor_flock();

rather than

$sheep_dog->{brain}{task}{monitor_flock} = 1;

At a high level, we do not particularly care what the internals of the object are. We only care what the object can do.

But, an object becomes harder to change the more its internals are exposed.

Polymorphism

$sheep_dog and $shepherd_boy both understood the same commands, so replacing the latter with the former was easier than it would have been otherwise.

---

I've had this in my scratchpad for a long time and I'm sure there's more that can be said, but I finally decided to post this after reading OOP's setter/getter method - is there a way to avoid them? in case anyone finds it helpful.

[Laurent_R]

Most tutorials that teach Perl OOP (Object Oriented Programming) focus on the nuts and bolts (which is important), but neglect the equally important "Why" or reasons for using OOP.

This is very true. Thanks for this very nice post which I would upvote several times if I could. :-)

Your fable is a very nice explanation as to the "why OOP?". I might actually want to re-use the idea for a Perl-6 OOP tutorial I am planning to write soon in French, if you allow me (I would of course give due credit and link to this post).

[Arunbear]

It's a relief to me that you found it useful. You're welcome to re-use the idea for your Perl-6 tutorial.

[Laurent_R]

Thank you very much.

[tiny_monk]

"Tell objects what to do, rather than micro-manage"

Hello, Arunbear. I certainly found this very helpful. The analogy between encapsulation and preventing micro-management is a good one. Thank you. :)

[TGI]

It's very refreshing to see an OO tutorial that does not promulgate attribute first/only design. The most egregious examples use a Point object with x and y attributes, and then demonstrate inheritance with a point in space that adds a z attribute.

In contrast, you have done an excellent job of emphasizing the messaging aspect of OO. Thank you!