|No such thing as a small change|
Re^2: Using the strict module in object oriented programmingby Codon (Friar)
|on Jul 25, 2006 at 17:18 UTC||Need Help??|
I would highly recommend using Inside Out objects. They keep others from dipping into the internals of your objects and thereby tying your hands through their poor practices.
Inside Out object do have limitations of sometimes being inconvenient for you as a user, but you as the maintainer can minimize those inconveniences by providing methods to dump the object, etc.
Perhaps more importantly for large systems, though, is the fact that method accessors can impose a performance hit by requiring the method call (as opposed to the hash look-up). So make sure that your accessors are well optimized in these situations.
If you have massive amounts of code that treat your objects as hashes and you don't want to refactor all of that code, you could look at refactoring your object to actually have a hash-based interface, but do method calls internallys. Lookups to non-existant "hash keys" could throw an exception. Take a look at the internals Regexp::Common (if you can follow it). It basically provides a nested hash interface, but each level of nesting acts both as a string (returns a pattern) and as a hash ref for deeper nesting. Rather cool. This could let you provide a strict "hash-like" interface to your objects.
Sr. Software Engineer, DAS Lead