Are design patterns something you invent as you go

Question

Are there set design patterns or does each individual sufficiently skilled software developer recognize and reduce their code to develop new patterns. Effectively creating their own "design" patterns.

Edit - Thanks for the responses. In reality I'm just refactoring and/or reducing code where the problem should have first been compared to existing design patterns before the code was written. If a match was found then I should have used it otherwise I'm simply refactoring code (which is not a bad thing and usually doesn't produce any new generally useful "patterns".)

Answer 1

There certainly are set, recognized patterns, as laid out nicely by the "gang of four"'s Design Patterns book. There are also patterns like CAB and SCSF that teams like the Microsoft Patterns and Practices team publishes. Does that mean that every pattern is covered? Certainly not. Developers and teams often come up with their own patterns that achieve their needs and that they use across their entire project.

So we'd like to not reinvent the wheel - use patterns that are already out there - but don't feel that you're constrained to only what others are doing.

Answer 2

You can and you may well will if you find yourself working in a big project with lots of extreme abstraction opportunities.

But, in general, design patterns are created by people who dedicate time to study software development in the large, from lots of own and other's projects.

http://en.wikipedia.org/wiki/Design_Patterns

Answer 3

There's no reason why you can't document your own patterns and anti-patterns as a way of sharing what you have learned with others; however, it is unlikely that every sufficiently skilled software developer is really going to discover something that hasn't already been discovered and documented elsewhere. Before publishing such a pattern, be really sure that another pattern doesn't already cover this case in order to avoid embarrassment later.

Answer 4

It's not really an either/or question.

Design patterns are general solutions to commonly encountered problems.

There are already a bunch of existing design patterns, each of which is appropriate for different problems (or different contexts), but the canon of design patterns isn't closed. There are certainly more patterns to be created and/or found.

The important thing to remember is that for a solution to really be a pattern, it needs to be general enough to be reused and it needs to apply to a reoccurring problem.

I think most programmers over time discover many of the same patterns independently. The real purpose of a catalog of design patterns is so that we can all agree once and for all what a particular pattern is and does, the facade pattern for instance, and then talk about it at a higher level of abstraction.

Answer 5

One of the primary uses of design patterns is a means to communicate design with other programmers. If you create your own, well only you will be aware of them and its not as useful for communication.

Usually developers do create our own design patterns, relating those to published patterns gives us new ideas and insights and improves our ability to communicate.

Answer 6

Software design patterns in general are applicative to recurring problems and are not project specific. Solutions you find for your own problem domain might be considered patterns if they are generic enough and reusable enough to be used in similar projects with similar problems.

The pattern repository is ever growing as more and more well-factored solutions are needed for arising problems software development.

Answer 7

If you read the literature on Design Patterns, you will see it is an umbrella term covering at least the following kinds of knowledge:

• Solutions to common problems

• Useful programming techniques that every programmer should know, i.e., that should be in common use

• Workarounds for lossage in commonly used languages (the original Gang of Four book contained many workarounds for lossages in C++ as compared to, say Smalltalk)

The other important aspect of design patterns is that they give programmers a common vocabulary for talking about this things. So, to be a design pattern, something has to be shared among the community and to be given an agreed-upon name. To answer your question, you might create a new design pattern, but it is a lot of work first to create something new, then to get the community to agree that it is worthwhile (and what to call it).

Certainly new problems will become common, useful new programming techniques will be invented, and new lossages will create needs for new workarounds. But it won't happen very often and to invent new solutions will be a ton of work. The Gang of Four book was almost entirely a codification of existing practice---the major new contribution of the book was the shared vocabulary. It's a worthy contribution but was disappointing to those of us who heard the hype and were hoping for something more than old wine in new bottles.

If you want to create new design patterns, leave well-trodden paths. For example, patterns are old news almost everywhere in the object-oriented world. (Though there are probably still opportunities for patterns around multimethod dispatch or prototype-based languages.) By contrast, the functional programmers are still waiting for somebody to identify and name most of the common solutions and good practices. If you are a great thinker and writer, you could have a dramatic impact on that field.

Answer 8

It's not a "pattern" until you have (1) needed it on several occasions; (2) can describe it in a fashion that's independent of the particular problem domain.

That said, if I had my way, I'd declare a moratorium on new patterns, or have an Official Pattern Language Repository where it doesn't become a "pattern" until it's been documented, peer-reviewed, and shown not to duplicate an existing pattern.

Mostly, when people talk about "making up a pattern" they really mean they've found a code snippet they want to reuse.