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

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

 



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




[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