Re: How to implement a plugin system?
| From: | Hamza Saglam | Date: | Tue, 07 Aug 2007 08:52:02 +0000 |
| Subject: | Re: How to implement a plugin system? | ||
| References: | 1 2 3 4 5 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-260268@lists.php.net to get a copy of this message | ||
""Nathan Nobbe"" <quickshiftin@gmail.com> wrote in message
news:7dd2dc0b0708061904i5578f8ewbe7ca511669f1dd5@mail.gmail.com...
> On 8/6/07, Stut <stuttle@gmail.com> wrote:
>>
>> Hamza Saglam wrote:
>> > Thanks for your response. However I am looking for something a bit more
>> > comprehensive :)
>> >
>> > I could do it as you suggested if I had only a few plugins. As I am
>> going to
>> > add loads of plugins over the time, rather than adding all the plugins
>> one
>> > by one, could something like a 'loader' class be implemented? What I
>> mean by
>> > that is, it will take the requested plugin names (with their own
>> parameters
>> > necessary) and load/initialise them.
>> >
>> > In semi-psuedo-code, it would be something like:
>> >
>> > foreach plugin suplied as the argument
>> > include the plugin
>> > initialise it
>> > end
>> >
>> > Perhaps I should change the question to: "Do you think something like
>> this
>> > would be efficient and useable? If not what sort of pattern would you
>> > follow?"
>>
>> What you're describing is the Factory pattern, and yes that's the most
>> efficient way to implement plugins. You should never load classes unless
>> you need them - it's a complete waste of time, and definitely not
>> recommended if you're going to have a lot of plugins.
>>
>> I would suggest you name your plugins X_plugin, Y_plugin and Z_plugin
>> (where plugin could be anything) because that adds a level of security.
>> Otherwise you could open yourself up to security issues because the user
>> could instantiate any class in your system.
>>
>> -Stut
>>
>> --
>> http://stut.net/
>>
>> > "Borokov Smith" <borokov@gmail.com> wrote in message
>> > news:46B77B4B.9020600@gmail.com...
>> >> Hey Hamza,
>> >>
>> >> require_once($chosenPlugin . '.class.php');
>> >>
>> >> $obj = new $chosenPlugin();
>> >> return $obj;
>> >>
>> >> And you can start from there.
>> >>
>> >> hth,
>> >>
>> >> boro
>> >>
>> >>
>> >>
>> >> Hamza Saglam schreef:
>> >>> Hello all,
>> >>>
>> >>> I am working on a project which needs to have some sort of plugins
>> >>> architecture and I am kinda stuck. Basically I want to give a list of
>> >>> items to the user, and according to his/her selection, I want to load
>> >>> relevant functionality into my application.
>> >>>
>> >>>
>> >>> I was thinking of having an abstract plugin class, and have the
>> >>> plugins implement that but then how would I actually load the
>> >>> plugins?
>> >>> Say for instance I want to load plugins X,Y,Z (and lets say i
>> >>> implemented them as [X|Y|Z].class.php) , should I just 'include' (or
>> >>> require) them? Or should I initialize all possible plugins and just
>> >>> pick the ones user has chosen (which sounds a bit pointless as it
>> >>> would load unnecessary stuff)?
>> >>>
>> >>>
>> >>> How would you go about doing something like this?
>> >>>
>> >>>
>> >>> Thanks.
>> >>>
>> >>>
>> >
>>
>> --
>> PHP General Mailing List (http://www.php.net/)
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
> allow me to elaborate. you want to aim for composition as a flexible
> alternative to sub-classing to extend behavior.
> Namely what you want is the Strategy pattern. Strategy allows you to
> compose objects at run time dynamically, thereby changing
> behavior in your system on-the-fly. The components are made similar by a
> common interface, which can be either the PHP
> *interface* or the PHP *abstract class*.
>
> these components each encapsulate a different algorithm or module as you
> would call it. and the interface makes the system simple
> to extend. to create a new module you simply implement the interface and
> it
> is interchangeable with the other modules in the system.
> the factory method pattern is sort of complex. it is used to encapsulate
> object creation. it is typically used to instantiate objects in a
> *family*
> *of products* which is defined by a common interface, ie the strategy
> pattern. the factory method is used to create products in a standard way.
> factory method pattern goes further, in typical implementations, by using
> template method in a parent class. this controls the boundaries
> of the modules in the system.
>
> the template method invokes the a factory method on a subclass to get a
> concrete object. it then operates on the the concrete object in a
> predefined sequence. the abstract base class can define different types
> of
> methods. the base class may specify methods that must be
> implemented by concrete subclasses. it can also expose hook methods, with
> a
> default implementation. these methods can be optionally
> implemented in the subclasses.
> after invoking the factory method to get a concrete object the factorys
> template method will invoke the remaining methods, mandatory, hook
> or otherwise on the newly created concrete object in a predefined sequence
> before handing the new object to the client code that called it.
>
> http://www.phppatterns.com/docs/design/strategy_pattern
> http://www.phppatterns.com/docs/design/the_factory_method
>
> -nathan
>
Hi Nathan,
That all sounds quite interesting. I'll try to apply it when I'm coding my
prototype :)
Thanks a lot,
Hamza.