Come for the quick hacks, stay for the epiphanies. | |
PerlMonks |
Re^2: Seeking inside-out object implementationsby Ovid (Cardinal) |
on Dec 06, 2005 at 22:42 UTC ( [id://514659]=note: print w/replies, xml ) | Need Help?? |
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. Cheers, New address of my CGI Course.
In Section
Seekers of Perl Wisdom
|
|