What design pattern do you use?

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

What design pattern do you use?

Post by GeXus »

Factory, Singleton, Observer, etc.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I think that is the wrong way to think about patterns. It is like asking an electrician what tools and types of circuits he uses -- the answer is all of them, it just depends on the circumstances.

Patterns are solutions to problems, so what you are actually asking is: What problems do you have?
(#10850)
GeXus
Forum Regular
Posts: 631
Joined: Sat Mar 11, 2006 8:59 am

Post by GeXus »

That makes sense, I'm not very familiar with the concept of "design patterns", although I do make use of them in different scenarios like you said. So is it inaccurate to say that you build applications using the factory design pattern?
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

So is it inaccurate to say that you build applications using the factory design pattern?
Yes
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

One builds applications with many patterns. I don't even think it's possible to build an application using only one pattern. Maybe a library, but not an application.
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post by jmut »

GeXus wrote:That makes sense, I'm not very familiar with the concept of "design patterns", although I do make use of them in different scenarios like you said. So is it inaccurate to say that you build applications using the factory design pattern?
Well, maybe not application build...but some part of it making use of factory pattern. If mentioning this will make you both saying 'aha I know what that is and how is used' you are already ahead in conversation. Else you will have to explain same idea/solutions with many more words.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

GeXus wrote:So is it inaccurate to say that you build applications using the factory design pattern?
Yes inaccurate. Patterns are solutions to problems. You might say, "You know, I have all these subclasses of a base class that I need to instantiate, but I really don't want to have to specify the class every time -- I'd rather have data in my configuration control which subclass is used." A solution to that problem is the Factory Pattern.

Patterns to two main things;

1. When you know how you want to solve a problem, they show a best practice solution.

2. When you don't know how to solve a problem, they provide a menu of problems with associated best practice solutions.
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

feyd wrote:One builds applications with many patterns. I don't even think it's possible to build an application using only one pattern. Maybe a library, but not an application.
I'd imagine a Factory Pattern library would be rather small.. maybe not as small as a Visitor Pattern library though. :lol:
Jeroen Oosterlaar
Forum Commoner
Posts: 37
Joined: Sun Nov 06, 2005 4:12 pm

Post by Jeroen Oosterlaar »

I use whatever design pattern is suitable for solving a certain problem. You shouldn't use design patterns with the sole purpose of using them.
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

If you were building a bed, you would probably need some things like nails, screws, a hammer, a drill and a screwdriver. Would you need a chainsaw? No.

Patterns work sort of the same way. You don't use a pattern just because it is available. You use it becuase the project calls for its use in a particular context.
User avatar
superdezign
DevNet Master
Posts: 4135
Joined: Sat Jan 20, 2007 11:06 pm

Post by superdezign »

Jeroen Oosterlaar wrote:You shouldn't use design patterns with the sole purpose of using them.
Unless you're in my object-oriented programming and design class. We *have* to find a use for the patterns we learn somehow. :P
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

Patterns are an odd thing in my books.. I never "use" them. I code, then when I've finished/look back/review, I can see these patterns in my code. I can identify patterns, but I'm yet to really code knowing that what I am about to develop is a "pattern x."
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Maybe you have it slightly wrong? When I learned patterns I was applying them purposefully - I'd say let's get rid of complex X by adding a Factory Y. Fast forward a few years, and after applying TDD or BDD I find it's more likely I'll iteratively refactor a class, recognise some shared behaviour, and push forward to a specific ideal. Very little consious thinking about "X Pattern, Y Pattern". The patterns are already integrated into my experience now so it just happens - as if by magic - I just start reacting to the clues without thinking hard.

When I'm explaining the code to someone else I might then sit back a moment and identify the patterns.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jenk wrote:Patterns are an odd thing in my books.. I never "use" them. I code, then when I've finished/look back/review, I can see these patterns in my code. I can identify patterns, but I'm yet to really code knowing that what I am about to develop is a "pattern x."
Of course, because patterns are just best practice solutions to problems. Once you know the best practice solution you don't need to "know" the pattern because it is now one of the many solutions you use.

When you were little you didn't know how to make a sandwich. You probably made a comic mess if you tried. So you watched experts (parents) first lay out two pieces of bread, apply mustard, etc. to both slices, then put on layers of meat/cheese on (only) one slice, then some lettuce and veggies on top of that, and finally flip the other slice over on top of the stack (condiment side down is critical :)). That's the sandwich pattern, but you no longer think of it as one. ;)
(#10850)
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Long before I started trying to formally understand patterns, I was unaware I was already familiar/using many, such as the singleton, factory, proxy, etc. When I began poking around the COM interfaces back in 1998 many of the articles I read used patterns to describe a component interface and give it a well known moniker. At the time I didn't understand why they named each interface a proxy or a factory, but eventually I just began to know of an object as a factory, etc.

I do start my designs with a existing pattern approach. I don't design first, then analyze and spot patterns, I use those that I know right off the hop and whenever I feel like what I have done is a best practice I sit and think of a name of an existing pattern which would likely match that which I just solved. For example today, I familiarzed myself with the Facade pattern.

Patterns gives you a vocabularly. For example: A facade is a common approach used by any experienced developer when simplifying an interface(s). Developers with OOP experience will typically refer to this as "wrapping" an object but wrapping is a generic definition which could include many different things:

1) You could be wrapping an object to change it's interface (ie: adapter pattern)
2) You could be wrapping several objects to *kinda* emulate inheritence and form one object interface (ie: composite pattern)
3) You could be wrapping a functional API and providing an OOP interface (AdoDB, Windows API, etc)
4) You could be wrapping one or more objects into a single *simplified* interface.

Each of these could be defined as "wrapping" but only the last one can be defined as a facade pattern. Its this slight adjustment in being specific that makes code much easier to write and understand when reading comments.

99% of the time design patterns are nothing more than common practices already used - perhaps with the exception being archtectural patterns like the MVC, because most frameworks will already have this done for you and you won't even be aware of it unless you develop a framework.
Post Reply