Hello tiny_monk,

The moment I saw $self->{'key'} = shift; being used in the setter and $self->{'key'} in the getter functions, it gave me the notion that the encapsulation was being broken. But I may be wrong. My understanding is that the object's innards should stay inside the object.

You are absolutely right, an object’s implementation (“innards”) should stay private to the object, to maintain encapsulation. But getter and setter methods are internal to the object — or, rather, they are internal to the class from which the object is instantiated. So it is quite appropriate for them to access the object’s innards. Encapsulation is broken only when an object’s implementation details are exposed or accessed outside the object.

While I understand that it is not advised that an API caller use $self->{'key} to access or update the object's attribute outside a class, ...

In this context, an object’s “API” is equivalent to its “interface”, that is, the totality of its public methods. And since the object itself is a blessed reference, it is often possible for code with access to the object to access its innards directly. But that breaks encapsulation, so external code should access an object only through its public methods.

In your original example, the methods set_color and get_color do not break encapsulation, because they are defined within package Fruit. But suppose we add the following lines:

$obj->{color} = 'blue';
print Dumper($obj);

[download]

The output is now:

22:39 >perl 1424_SoPW.pl
$VAR1 = bless( {
                 'name' => 'apple',
                 'color' => 'green'
               }, 'Fruit' );
$VAR1 = bless( {
                 'name' => 'apple',
                 'color' => 'blue'
               }, 'Fruit' );

22:40 >

[download]

which shows that we have again altered the apple’s colour. But this time we have done so by accessing the object’s internals directly, which does break encapsulation.

Unlike other OO languages, Perl allows this to happen, but that doesn’t make it a good idea! Here’s a famous quote from Larry Wall:

Perl doesn’t have an infatuation with enforced privacy. It would prefer that you stayed out of its living room because you weren’t invited, not because it has a shotgun.

But there are also techniques for enforcing privacy. See the section “Using Closures for Private Objects” in Chapter 12 of the Camel Book (4th Edition, 2012, pp. 446–9), and modules such as MooX::ProtectedAttributes for use with Perl object systems such as Moose and Moo.

Hope that helps,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

In reply to Re^3: OOP's setter/getter methods - is there a way to avoid them? by Athanasius
in thread OOP's setter/getter method - is there a way to avoid them? by tiny_monk

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.