Re: Re: What's Your Favorite Design Pattern?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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



[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux