In the p5p discussions of Dave Rolsky's new Perl OO tutorial and OO recommendations, Johan Vromans and others have mentioned
that in good OO programming, one should not violate encapsulation by directly accessing an
objects underlying data structure.
$self->{foo} = "Look Ma! No encapsulation"; # don't do this, they say
In general that is true, but not always, We should avoid absolutist language, especially in tutorials. I'll come to an example of that.
For Nama, I generally use a setter with this syntax:
$self->set(foo => "bar");
The set method (inherited from a parent class based
on Object::Tiny) makes sure the key is a legal one.
Because it looks distinct, I'm not likely
to use it unless I want really write access to that attribute.
This simple approach allows me to manage object attributes culturally, i.e.
without specifying them as read-only or read-write.
In an app of 13k lines, the 'set' method appears just 110 times.
But it's still possible to directly modify an object
in other ways:
my $self = Object->new( foo => [qw(this is a pen)] );
my $array_ref = $self->foo;
$array_ref->[3] = 'lobster';
print $self->as_string # "this is a lobster"
I am living with that.
The other point is that I believe there can be legitimate
reasons to violate encapsulation. I recently found a good example. Nama allows you to create
a new track object that refers to WAV files
with a basename other than the track's own name.
For an ordinary track, the name matches the WAV file:
my $Mixdown = Track->new( name => 'Mixdown'); # associates with Mixdown.wav
Here is a track created by the 'link_track' command,
that also associates with Mixdown.wav.
my $song = Track->new( name => 'song', target => 'Mixdown');
Here is a track created by the 'new_region' command,
that indirectly associates with the same file.
my $final_song = Track->new( name => 'final_song', target => 'song' )
Here is the code I use so that $final_song->target returns
'Mixdown':
package Track;
sub target {
my $self = shift;
my $parent = $Track::by_index{$self->{target}};
defined $parent && $parent->target || $self->{target};
}
Now there could be some discussion about my using the track
name (as opposed to a Track object) as the value for the
'target' field. In short, this design decision has made it
easy to serialize and to debug by dumping objects as YAML.
Regarding encapsulation, the point is that accessing $self->{target} is
essential for this code to work.
Accessing the underlying hash provides the behavior I want.
I think it's simplistic to assume that every new user
could or should find other ways to achieve this behavior
without violating encapsulation.
Our tutorials should respect readers' intelligence.
I think we can tell them what is good practice, without
prescribing an idealistic straitjacket.
Even if I'm missing an easy solution that doesn't access the
hash, why should I be required to find one?
For example, I could do it this way:
package Track;
sub _target{ $_[0]->{target} }
sub target {
my $self = shift;
my $parent = $Track::by_index{$self->_target};
defined $parent && $parent->target || $self->_target;
}
But the code is no clearer and the first line still
violates encapsulation.
I can see the importance of respecting encapsulation in
large projects using others' OO libraries, but not all use
cases fall into that category.
I blog about Perl.