On Tue, Feb 7, 2012 at 2:31 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Tue, Feb 07, 2012 at 09:02:00PM +0000, Tim Streater wrote:
>> On 07 Feb 2012 at 19:34, Daniel Brown <danbr...@php.net> wrote:
>> > On Tue, Feb 7, 2012 at 13:56, Mike Mackintosh
>> > <mike.mackint...@angrystatic.com> 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:



> 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

Reply via email to