<?xml version="1.0" encoding="windows-1252"?>
<node id="184174" title="OOP: Plugin Style Development" created="2002-07-22 14:49:26" updated="2005-06-17 15:11:52">
<type id="115">
perlquestion</type>
<author id="183034">
jk2addict</author>
<data>
<field name="doctext">
&lt;p&gt;Long time listener, first time caller: be gentle.&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
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).
&lt;/p&gt;&lt;p&gt;
For example, let's say I'm working on a shopping cart module. It has the usual
methods: add, remove, empty, save, etc.
&lt;/p&gt;&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
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.
&lt;/p&gt;&lt;p&gt;
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.&lt;/p&gt;</field>
</data>
</node>
