What design pattern do you use?
Moderator: General Moderators
What design pattern do you use?
Factory, Singleton, Observer, etc.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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?
Patterns are solutions to problems, so what you are actually asking is: What problems do you have?
(#10850)
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.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?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.GeXus wrote:So is it inaccurate to say that you build applications using the factory design 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)
-
Jeroen Oosterlaar
- Forum Commoner
- Posts: 37
- Joined: Sun Nov 06, 2005 4:12 pm
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
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.
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.
- superdezign
- DevNet Master
- Posts: 4135
- Joined: Sat Jan 20, 2007 11:06 pm
- Maugrim_The_Reaper
- DevNet Master
- Posts: 2704
- Joined: Tue Nov 02, 2004 5:43 am
- Location: Ireland
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.
When I'm explaining the code to someone else I might then sit back a moment and identify the patterns.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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."
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
(#10850)
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
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.
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.