Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

Re^2: Seeking inside-out object implementations

by Ovid (Cardinal)
on Dec 06, 2005 at 22:42 UTC ( #514659=note: print w/ replies, xml ) Need Help??

in reply to Re: Seeking inside-out object implementations
in thread Seeking inside-out object implementations

Not having encapsulation means that it's really, really easy for someone to silently and mysteriously break your class by overwriting a hash key. I've had to deal with this and it's not fun. For smaller systems, it's less of a problem but bigger systems require more careful planning. Admittedly good test suites catch the errors, but they frequently don't tell you how to fix 'em.

The main problem with inside-out objects is that they're currently even more of a hack than Perl's current OO system. With clean OO, we wouldn't even be worrying about this.

I might add that Class::BuildMethods does not override UNIVERSAL::DESTROY and is very lightweight. It gives you encapsulation in a very easy to use manner and can be incorporated into existing classes. Further, the constructor is usually ridiculously easy to use. It's much easier than its counter-parts. The trade-off being that you only get one style of getter/setter and you can only store a single value (hashes must be passed as hashrefs, for example. By restricting the interface, the code is simpler and faster. You want three simple getter/setters?

use Class::BuildMethods qw/name rank serial/;

You can mix them with any others you want and add defaults or validation as needed.


New address of my CGI Course.

Comment on Re^2: Seeking inside-out object implementations
Download Code

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2016-05-29 11:08 GMT
Find Nodes?
    Voting Booth?