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);

[download]
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();

[download]
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();

[download]
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();

[download]
$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();

[download]
rather than 
$sheep_dog->{brain}{task}{monitor_flock} = 1;

[download]
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.

In reply to OOP: A Bird's Eye View by Arunbear

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.