Page 1 of 2

What design pattern do you use?

Posted: Mon Oct 29, 2007 1:03 pm
by GeXus
Factory, Singleton, Observer, etc.

Posted: Mon Oct 29, 2007 1:22 pm
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?

Posted: Mon Oct 29, 2007 3:02 pm
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?

Posted: Mon Oct 29, 2007 3:08 pm
by Luke
So is it inaccurate to say that you build applications using the factory design pattern?
Yes

Posted: Mon Oct 29, 2007 3:12 pm
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.

Posted: Mon Oct 29, 2007 3:15 pm
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.

Posted: Mon Oct 29, 2007 7:08 pm
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.

Posted: Tue Oct 30, 2007 5:16 am
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:

Posted: Sat Nov 24, 2007 12:42 pm
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.

Posted: Sat Nov 24, 2007 1:30 pm
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.

Posted: Sun Nov 25, 2007 7:40 pm
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

Posted: Mon Nov 26, 2007 5:38 am
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."

Posted: Mon Nov 26, 2007 8:29 am
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.

Posted: Mon Nov 26, 2007 3:03 pm
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. ;)

Posted: Mon Nov 26, 2007 5:05 pm
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.