in reply to Re: regex transforms of object attributes
in thread regex transforms of object attributes

Violating encapsulation simply to avoid a transient variable seems like a poor trade to me.
  • Comment on Re^2: regex transforms of object attributes

Replies are listed 'Best First'.
Re^3: regex transforms of object attributes
by Plankton (Vicar) on Jun 19, 2004 at 00:02 UTC
    Really? Why you say that? The only "encapsulation" here is by convention. Perl does not have syntax to enforce information hiding. Does dealing with the attribute cause the attribute to become uncapsulated? I don't think so. The use of a variable to store the attribute does and has more potential for misuse in the code. Some thing that "encapsulation" is suppose to prevent.

    Plankton: 1% Evil, 99% Hot Gas.
[reply]
      Who says that the $self->content variable stays a variable in the future? Dealing with the attribute doesn't cuase the attribute to become uncapsulated, but it does violate information hiding. An object has a published interface (the methods) which are more or less guaranteed to work. The upside is that when the author of the module/class feels there is a better way to implement things, she can do that without changes to the external interface.

      Of course you can use the attribute directly. No one is stopping you. It'll probably work just fine. Just don't get upset when it suddenly breaks your programs when you install a new version.

      Arjen

[reply]
[d/l]
        But honestly: if it's settable and gettable, what are the chances that it's not going to be a simple variable?

        And a minute after posting that, I encountered this node, that answered my question one way: it's possible that a value needs to be encoded to be stored, and decoded to be retrieved. So there I have it. On the other hand, if you use a tied variable, you can do your encoding and decoding transparently and not break encapsulation...

        We're not really tightening our belts, it just feels that way because we're getting fatter.
[reply]

      This will not break due to changes in $obj's interface

          my $content = $obj->content();
    $content =~ s/ome/thin/g;
    $obj->content( $content );

      [download]

      This might

          $obj->{content} =~ s/ome/thin/g;

      [download]

      The former uses the interface published by the module author. The latter relies on the internal workings of the object itself, and therefore violates the encapsulation of the object's data.

      The risk that comes with the latter form (your code is now tied to the current version of Whatever::Module, and that requirement is neither enforced nor documented) just doesn't seem worth the gain of avoiding creating $content.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom