more useful options | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
Some argue that the behavior or subclasses (or subtypes) should not change . . . I dunno. HTML::Template::Dumper significantly changes the behavior of HTML::Template. If people want to argue that this breaks Liskov, that's fine, but it doesn't stop HTML::Template::Dumper from being useful. $object->as_string One important benifit is that YAML/Data::Dumper only show the state of the object's internal data structure, but not lexicals used for storing private data (see below). It might be private, but if it's for debugging or human-readability, it might still be important to print it out. So a mere Dump($obj); is often not enough. Other observations: 1) One thing I often see is people storing things in the object's structure that should be private, or storing things in lexicals that should be accessible to subclasses. As a general rule, if you want a subclass to get at it, it should be in the blessed reference of the object. Or provide accessors/mutators that are only available to subclasses (not public, unless your design explicitly calls for it). If the data needs to be truely private, put it in lexicals declared at the top of the package. 2) If you have a factory method, do not hardcode the name of the class. Instead, put it in a subroutine, like this:
This better supports subclasses, which would otherwise need to override the entire bar_factory method (which could be extremely complex). Now they only need to say sub BAR_CLASS { 'My::Bar::Subclass' } to change exact output of the factory method. (It's the responsibility of the subclass to make sure My::Bar::Subclass implements the same methods as My::Bar). 3) Calling all your own methods should be done in $obj->method( @args ) form. Not method( $obj, @args ) or (worse) method( @args ). Both the bad examples break inheirtance, and the second one isn't a method at all. I could see an argument made for the method( $obj, @args ) form if performance is a concern and you don't care about subclasses or if it's a private method, but I see no excuse for the second form. 4) Document protected methods. Unlike some other languages, Perl doesn't have any very good ways to specify what methods should only be accessible to subclasses (though it has a multitude of hacked solutions). Ultimately, you need to document your protected methods, with warnings of fire coming down from heaven if somebody on the outside uses them. And make sure fire won't come down on ligitimate subclasses. ---- : () { :|:& };: Note: All code is untested, unless otherwise stated In reply to Re: Often Overlooked OO Programming Guidelines
by hardburn
|
|