What design pattern not in go4 that I should know of??
Just wondering what your input are?
Printable View
What design pattern not in go4 that I should know of??
Just wondering what your input are?
A googolplex of them... one for each new problem you face to which you can't directly apply a pattern described on that catalogue. The authors do make it clear somewhere, I think, that the idea is not to apply the patterns directly, but to build your own patterns based on the described ones.Quote:
Originally Posted by kypronite
...
If you want to reduce Gang of Four, use GoF, not Go4.
I disagree,like what???Quote:
Originally Posted by Mario F.
I think googolplex for design pattern is really exaggerating...
There some design pattern that are difficult to find like analysis matrix...
I think what Mario is trying to say is that the design patterns are suggestions on how to solve a particular set of problems, but that can be applied to many other problems. But at the same time, there is all sorts of problems that the design patterns can not solve directly or with changes.
Since there is an ALMOST INFINITE number of programming tasks, one can quite easily find MANY solutions that are not covered by the design patterns.
And it doesn't matter if GOF comes out with 10, 20 or 100 more design patterns, there will still be problems out there that are not covered by those.
On the other hand, having ready made solutions for some of the common problems that occur quite often in programming is a good start. Now, depending on what sort of programming you do, the chances of hitting a problem that is not covered by these design patterns will vary. I'm pretty sure that in the area where I work, inside an operating system, I find more cases where the design patterns are not working even after minor modifications, whilst someone writing "common" applications will probably find many more patterns that match their needs.
In summary, what I'm trying to say is that there is no such thing as a finite number of designs to solve the infinite number of problems that programming will pose to us.
--
Mats
What do you want to know? That one of design pattern missing from the GoF is recursive functions?
It's true that the term Design Patterns lacks a formal definition, but you are certainly smart enough to understand that the GoF addresses design patterns from an OOP overview and leaves behind non OOP languages (some might argue Design Patterns only make sense on OOP, but I strongly disagree).
On the other hand, whenever you create the core solution to a problem that you can reuse over and over again to solve similar problems you are creating a Design Pattern. Similarly, when you ignore existing design patterns and create your own reusable solution to a known problem, you are creating a Design Pattern, even if it is redundant.
Theoretically there's an infinite number of possible Design Patterns for each problem, and an infinite number of problems. Naturally some design patterns may be better than others and some problems may be solved with the solution from another problem. But infinite - x = infinite
EDIT: matsp beat me on the minute mark.
ok,my bad here.
I guess I overexcited about pattern here.Since I spend many hours coding some sort of 'if and else' logic today.On my way back,I started thinking about ways to conquer the problem I encounter earlier.Then there's this eureka moment,I remember about state pattern.Hence my overexcitement.
But hey,no problem in asking right.
Absolutely not.Quote:
Originally Posted by kypronite
"many if" can be solved by statemachines, but also tables [an oldfashioned technique of using an array to describe what input gives what output in some way or anohter] are a good possible help there.
--
Mats
Let's not forget that with each new design pattern comes a new anti-pattern as well. New ways to really shoot yourself in the foot. I feel it's just as prudent to study anti-patterns as it is design patterns.