On 8/6/07, Stut <stuttle@xxxxxxxxx> 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@xxxxxxxxx> wrote in message > > news:46B77B4B.9020600@xxxxxxxxxxxx > >> 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
