Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight
 
PerlMonks  

Re: Encapsulation through stringification - a variation on flyweight objects

by dragonchild (Archbishop)
on Apr 01, 2003 at 23:18 UTC ( #247376=note: print w/ replies, xml ) Need Help??


in reply to Encapsulation through stringification - a variation on flyweight objects

Personally, I think that going for this kind of hard encapsulation is self-defeating. The whole point of OOP is to decouple your code. If your colleague is violating this decoupling, then it is incumbent upon you to educate your colleague. Education is better done non-coercively. If your colleague refuses to learn, quit. Life is too short and, despite the general slowdown, the jobs are out there.

If you're providing a module for general consumption, you don't have to do B&D development. This is not consistent with the culture of the entire LAMP model. If someone abuses your appropriately-documented interface, that's their problem, not yours. It's your job to make your stuff mistake-proof, not fool-proof. Fools are infinitely more cunning than any of us can ever be.

Now, this form of implementing flyweight objects is flyweight only in the creation and memory usage (and if you're using stringification of hashrefs as your index, you don't even have that benefit).

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.


Comment on Re: Encapsulation through stringification - a variation on flyweight objects
Re^2: Encapsulation through stringification - a variation on flyweight objects
by adrianh (Chancellor) on Apr 02, 2003 at 10:19 UTC
    Personally, I think that going for this kind of hard encapsulation is self-defeating. The whole point of OOP is to decouple your code. If your colleague is violating this decoupling, then it is incumbent upon you to educate your colleague.

    We've had this discussion before but I just can't let it go :-)

    I agree when the violation is deliberate. The problem with the "normal" perl OO model is that you can interfere accidentally with "private" methods and attribute.

    Even if they completely stick to the documented API they can be bitten if there is a change to the private implementation if it is done in the naive perl OO style.

    The good news is that, in my experience, it doesn't happen very often. However, I'm still very much looking forward to being able to get around this nicely when perl6 hits the streets.

      The problem with the "normal" perl OO model is that you can interfere accidentally with "private" methods and attribute.

      This kind of assertion demands an example. I humbly await your response.

      ------
      We are the carpenters and bricklayers of the Information Age.

      Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        package Foo; sub new {return bless {} => shift} sub oogle {my $shelf = shift; $self -> {key} = shift} package Bar; our @ISA = qw /Foo/; sub gurgle {my $self = shift; $self -> {key} = shift;}

        Both Bar and Foo happen to use the same key, because there's no encapsulation.

        Perl na(t)ive OO model stinks, because you've to work hard to get encapsulation. (Note: I'm not saying I want private stuff, I just want encapsulation of the implementation). I do not know a common language whose OO model sucks more than Perls.

        Abigail

        Perhaps these examples demonstrate it, although German, they should be understandable. It's kind of a summary of that discussion some time ago.

        --
        http://fruiture.de

        This kind of assertion demands an example.

        I live for examples ;-)

        Bob writes a module to manage persistent objects:

        The documented API are the methods uuid, load, save & mark. The hash key _change is an implementation detail.

        Now, Mary's writing a module for representing the state of vending machines. She needs the information to persist, finds Persist on CPAN, and decides to use this as her base class.

        Now, despite sticking to the published API, Mary is going to have a nasty time debugging her code. She'll have to go and read the source for Persist to find out that Bob's implementation detail ($self->{_change} = boolean value indicating whether an object has changed) clashes with her implementation detail ($self->{_change} = object representing available change in the vending machine).

        Note this is not deliberate. Mary is not sneaking a look inside Bob's module and using the hash for her own nefarious means - it's an accident.

        You get exactly the same issue with "private" methods. What if Bob decides to extend Persist to only load the objects when needed. As part of this he adds a _loaded method that will return true when the object is fully loaded from backing store. Without changing the published API his new version of Persist will break when used with Mary's old VendingMachine module - because it clashes with Mary's _loaded method. Nasty.

        There are, of course, ways around these issues. You can use inside out objects to get around problems with attribute clashes. You can use alternate calling styles to get around problems with private methods. However these, and other techniques, all require a fair amount of discipline and expertise to use well.

        Good encapsulation is a pretty darn basic feature of an object oriented language. In my opinion its absence hurts perl. It makes it harder to write good modular reusable code. It makes it easier for people to score points in those pointless language flame fests. Good encapsulation should be a basic part of perl (and will be in perl6... huzzah!).

        Enough ranting :-) You might also find these exchanges on private attributes and private methods of interest.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://247376]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (4)
As of 2014-11-27 20:11 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (187 votes), past polls