Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Object Oriented configuration valuesby trs80 (Priest) |
on Feb 10, 2003 at 04:25 UTC ( [id://234012]=perlmeditation: print w/replies, xml ) | Need Help?? |
Update: There is a version 2 of this that I consider better, but you should read this before reading version 2
Intro When programming in OO Perl I prefer to keep everything, including configuration options, accessible via a method rather than directly accessing the objects data structure. The sometimes tedious part is adding all the methods as the configuration file grows. I don't want to hard code my accessor methods and I certainly don't want to modify my API modules everytime a new configuration option is added. What follows is a method for keeping both the API developer and the application developer happy and providing flexibility without complete loss of control. This was in part was started after I saw that many of the WWW::Search::X modules were directly accessing the object data structure and felt that level of access was "dirty."
A Good API
The purpose of an API is to provide building blocks for application developers. API modules once deployed are expanded, but the base functionality has to remain. These modules remain in use for a long time hopefully lasting for months or years without major revision once deployed. So how can we achieve this goal and keep an OO interface while expanding configuration options at the developer level and keeping the developer from creating their own accessors?The Concept We start off with the Class::Accessor module. Class::Accessor creates accessor methods within your class by passing a list of the method names you want generated into its mk_accessors method.Creating Our "Base" Class We are going to create an initial module named Base.pm for this OO project. We use Class::Accessor within the Base module and from an application level the usage of OurApp::Base class is hidden. The Base module is for the API or object creator not the person writing applications based on it. We decide on our module name first, the one we want people to use. Lets call it OurApp So inside of OurApp.pm we do:Configuration File ContentsThat was a lot of work :), but what did we do? We created a sub class of our Base class file. The Base package will handle all our actual class creation activities. So lets make that class now.
Test Script What This Does for Us Now if we run this the configuration file keys will be come accessor methods with the values as assigned in the conf file, but we can also set them to new values using the accessor method. Further Exercises/Thoughts Add values to the configuration and you see there is no need to modify the API level modules, this allows you make your application more decoupled because you can add variable elements at the configuration/development level and developers can create new client/need defined methods so the application keeps an OO interface as much as possible. Caveats There are some hidden and not so hidden dangers to this technique. One danger is repeating a configuration variable (key) names or colliding with built in real methods, but naming conventions and guidelines can help avoid that. The technique I have adopted is to name the configuration variables conf___, which will likely not occur directly in the API at any point. Another hidden danger is that there is no way to document the accessors efficiently since they are often added by the developer and never moved into the core, but then that is reasonable to some extent since the API has served it's purpose. The end developer has the responsibility to adequately document their specific needs.
Back to
Meditations
|
|