""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message news:7dd2dc0b0708061904i5578f8ewbe7ca511669f1dd5@xxxxxxxxxxxxxxxxx > 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 > Hi Nathan, That all sounds quite interesting. I'll try to apply it when I'm coding my prototype :) Thanks a lot, Hamza. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
