Subclassing to change configuration seems like a poor use of subclassing. You shouldn't create a subclass in order to change the data values in an object. If you later had some better reason to use inheritance you'd have to fit your inheritance into a existing tree of classes, which would likely be very complicated if you got it to work at all. Inheritance is best reserved more as a "last resort" in a design. The "is a" relationship is too inflexible and so should be invoked sparingly.
I hate Repeat::The::Really::Long::Class::Name->new() syntax. Package names should be very clear and globally unique and you should only ever mention them once in your code. I much prefer to have a (pre-configure) factory for constructing any objects:
my $Valid; use Form::Validator( Factory=>\$Valid, AllowedTags=>[...], OtherConfig=>..., ..., ); # ... my $obj= $Valid->new( ... );
That way you can use the same module two or more ways from the same code. You can store your pre-configured factory in a file-scope lexical, a package global, as a member of each object, anywhere you can store a lexical.
And, in practice, in Perl, it is often natural to just allow any object to be a factory for its own class. $obj->new( ... ) creates a new object using the configuration information from $obj. Then you may want a way to create a pre-configured but empty object to use just as a factory.
- tye
In reply to Re: Where to store class configuration settings in a module used by multiple applications (factory)
by tye
in thread Where to store class configuration settings in a module used by multiple applications
by clinton
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |