On Tue, Feb 7, 2012 at 2:31 PM, Paul M Foster <paulf@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Feb 07, 2012 at 09:02:00PM +0000, Tim Streater wrote: > >> On 07 Feb 2012 at 19:34, Daniel Brown <danbrown@xxxxxxx> wrote: >> >> > On Tue, Feb 7, 2012 at 13:56, Mike Mackintosh >> > <mike.mackintosh@xxxxxxxxxxxxxxx> wrote: >> >> I was curious to see what everyones favorite design patterns were, if you use >> >> any, and why/when have you used it? >> >> >> >> Choices include slots and signals (observer), singleton, mvc, hmvc, factory, >> >> commander etc.. >> > >> > Mine is apparently CPSV (Commentless Procedural Spaghetti Vomit), >> > as that's what I encounter no less than 80% of the time in the wild. >> >> Since I have no idea what anyone is talking about, I can only conclude that you're playing Mornington Crescent (q.v.), on a non-standard board. >> >> -- >> Cheers -- Tim >> > > Design Patterns are Way Nifty Kewl patterns of code which are supposed > to facilitate certain types of operations. (Was that sarcasm you > detected? Yes it was.) > > For example, the Singleton pattern. Let's say you had a configuration > class that held the configuration values for your application, and you > wanted to make sure there was only one object of that class > instantiated, no matter how many times it was called in your code. You'd > arrange the code and call the class in a certain way to ensure that only > one object of that class resulted. To make your configuration class a > "singleton", you'd probably make the class have a *private* constructor > (so no outside routine could call it), and then provide a method called > get_instance() which tested for the existence of an object of that > class. If such an instance was found, someone calling > configuration::get_instance() would simply get the existing object > returned to them. Otherwise, configuration::get_instance() would > instantiate the class and then return the new object to the caller. > > As you can see, that's a peculiar way of setting up your code for a > specific purpose. Other design patterns do other things and dictate > setting up things in other ways. > Here's a code example of the above explanation: http://pastebin.com/mTrybi6u HTH, Tommy > The definitive work on this (and where it first gained the most > publicity) is a book called "Design Patterns" by four authors (Gamma, > Helm, Johnson and Vlissides). It essentially contains a chapter about > each (known at the time) design pattern and some pseudocode about how it > might be constructed. I imagine the authors looked at a lot of code and > discovered that programmers were coming up with code that, in each case > was remarkably similar for solving certain types of programming > problems. So they codified what that found and wrote a book about it. > > I have the book on my shelf, and it's decent technology, but you could > spend your whole career and never use any of it, and get along just > fine. > > Paul > > -- > Paul M. Foster > http://noferblatz.com > http://quillandmouse.com > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
