Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid

OOP: A Bird's Eye View

by Arunbear (Prior)
on Oct 27, 2015 at 16:04 UTC ( #1146129=perlmeditation: print w/replies, xml ) Need Help??

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.



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


Tell objects what to do, rather than micro-manage e.g.
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.


$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.

Replies are listed 'Best First'.
Re: OOP: A Bird's Eye View
by Laurent_R (Canon) on Oct 29, 2015 at 17:06 UTC
    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).

      It's a relief to me that you found it useful. You're welcome to re-use the idea for your Perl-6 tutorial.
        Thank you very much.
Re: OOP: A Bird's Eye View
by tiny_monk (Sexton) on Oct 28, 2015 at 08:30 UTC

    "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. :)

Re: OOP: A Bird's Eye View
by TGI (Parson) on Dec 30, 2015 at 02:00 UTC

    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!

    TGI says moo

Re: OOP: A Bird's Eye View
by sundialsvc4 (Abbot) on Oct 28, 2015 at 16:58 UTC

    The thing that I like best about OOP is that it puts source-code and data together, and, in full-featured OOP implementations, prevents the source-code from being somewhere else.   As I said in the other thread, when you are dealing with a real-world application you could be looking at hundreds of thousands or millions of lines of code scattered among hundreds of modules.   Good OOP design greatly reduces the amount of source-code that you must investigate when you are planning how to carry-out a change ticket.   (Without OOP, a bomb could be hidden a-n-y-w-h-e-r-e.)   It also provides a great, easy-to-find place to put a breakpoint or a trace-message.

    I rarely make “deep” use of class hierarchies, because this can lead to one of the down-sides:   excessive coupling.   (A sheep-dog and a shepherd-boy might both know how to herd sheep, but that is an abstract similarity that would not extend to any sort of common-code implementation.)   I also eschew features like multiple-inheritance and “friends.”   I want you to be able to quickly identify and go-to the source module that teaches a sheep-dog how to herd, but once you get there I want you to need spend very little time understanding how it works.   I want you to see a method-call and be able to immediately identify “at a glance™” what code will be executed, and to always, always, always be right.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://1146129]
Approved by kcott
Front-paged by Old_Gray_Bear
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (16)
As of 2018-07-16 14:48 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (341 votes). Check out past polls.