Clear questions and runnable code
get the best and fastest answer
OOP: Plugin Style Developmentby jk2addict (Chaplain)
|on Jul 22, 2002 at 18:49 UTC||Need Help??|
jk2addict has asked for the
wisdom of the Perl Monks concerning the following question:
Long time listener, first time caller: be gentle.
I've seen the topic of OOP/inheritence covered here more than a few times. I wade through the Camel and Damian books an a seemingly daily basis.
While most of it makes several degrees of sense to me, I keep wanting more in terms of creating OOP modules in a plugin-style of development (my apologies for forgetting the _type_ of inheritance this is at the moment).
For example, let's say I'm working on a shopping cart module. It has the usual methods: add, remove, empty, save, etc.
Now I want to make this module flexible as possible by creating different I/O schemes underneath so the cart contents could be stored in LDAP, FTP, File, Hash, Session, DBI, etc.
This is where I get lost. I know theres more than a few ways to go about this, but what are the best ways to do it? I understand the side of OOP which I can extend the module to include a myfoo method, or override the add method. But I can seem to grasp how to ensure that the base module ALWAYS has the expected methods _and_ parameters and only the implementation changes.
I think If I could find some examples of this stuff, I'd be ok. (In my head at least) Most of the OOP examples I see are based on extending a base class by adding functions to it. It seems very few examples cover the other end of the fence: creating I/O filters/interfaces to parent classes.
The methods I've seen range from passing the I/O module name as a parameter or via %ENV to using the I/O modules directly and interweaving public/private methods.
Disclaimer: I did come from the *cough* windows *cough* side of OOP, where there are interfaces in COM that are 'implemented' by the I/O modules or plugins, so if an object implemented an interface, you were assured that it accepted the methods/parameters required. This is probably why I'm having a hard time wrapping my brain around this in Perl OOP.