When are design patterns the problem instead of the solution? [closed]

Answer 1

I've also not yet found a use for GoF "Design Patterns" in my code. The coderati appears to have latched on to the GoF book, and it is now expected in the majority of companies that you know them and apply them. Just today I had an interview and was asked which patterns I knew and had used, and how I would apply them to an enterprise app for a major bank.

The generic idea of learning from our previous projects obviously makes sense. What doesn't make sense is the hype and cult around the specific GoF patterns, people mistaking them for good-coding practice, and being expected to love and embrace them in order to be called a competent developer.

So to answer your question, I'd say the GoF idea of design patterns is misunderstood and overused by most. We need to mature into a higher-level use of design patterns as a general learning tool that applies to the way we learn and refine OO--not just as 20 cookie-cutter ideas to memorize and impose on programs. There is no silver bullet.

Answer 2

I believe Paul Graham's claim is that design patterns should be expressed in the language. If there is a X pattern, it means that people are forced to rewrite sequences of code to do it, and there should be a language-specific way of expressing it. This could be built into the language (although that's awkward, and can create new design patterns), or it could be automatable within the language (such as Common Lisp macros; C++ templates, particularly when used in weird ways, can do much the same sometimes).

For example, let's consider a much simpler pattern: the incrementing loop. Having to do something on each element in a sequence is quite common, and if we didn't have something corresponding to a for statement we would doubtless adopt some common coding convention to express it, and somebody (or some foursome) would package that together with other similarly elementary constructs and write a book about it.

Similarly, if using a Factory pattern, either a language could include a Factory feature, or it could be possible to automate it within the language. Specifically, Paul wants to be able to write a Lisp macro to implement it, rather than write Factories himself over and over again.

The danger with using a design pattern is that it's a familiar code framework we keep typing, and therefore we have chunks of code that we tend not to read and write with full attention. The inconvenience is that they're code we have to type again and again, and the feeling that the rewriting really should be automated.

Whether patterns are an essential part of using languages, like the GoF says, or can be abstracted away, like PG says, is fundamentally an empirical question, probably best solved by looking for languages where the patterns themselves are unnecessary and observing to see if they really need new patterns.

Answer 3

Programming languages, like spoken ones, provide you with the vocabulary to say whatever you want. Patterns only describe a way to say things that allows people to know what you're talking about at a higher level.

If you'll indulge me in a metaphor: Writing music is a common 'problem' and music is often (obviously not always) loosely composed as some kind of variation on the following:

verse chorus verse chorus verse chorus chorus

Which, indeed is a 'pattern'. You still need to write the song though and not every song written will work well using this pattern.

The point I'm trying to get at is that patterns aren't a plug-play-done solution for programming, or music. They're a guideline to get you started and a springboard from which you can make something that suits your need.

Answer 4

Patterns are really just a way of describing how things work. It is a way of classifying them. Are there some programs that overuse them? Sure. The biggest advantage of having patterns is that by classifying something as this or that, everyone is on the same page (assuming they have the level of knowledge to know what is being talked about.). When you have a system with 10,000 of lines of code, it becomes necessary to be able to quickly determine how something is going to work.

Does this mean that you should always use patterns, no. That will lead to problems to force things into a classification, but you shouldn't shy away from them either.

Answer 5

During the design phase of my programs, I often break down the problem first, and once I have it broken down then I can easily start to recognize patterns inherent within the design. At that point, I can begin to apply well-known design patterns so that when it comes time to communicate or implement the design, I have a common language I can use for communication, and hopefully I can re-use some generic objects that were previously implemented during the implementation of a similar pattern.

Often times, when design patterns are applied incorrectly, it's because the process happens in reverse. Programmer Joe (my apologies to those of you named Joe) reads a book on Design Patterns, and says "Ok, I understand Design Pattern X, now how can I apply it to my application?" This is wrong.

Design patterns can be a mighty weapon, but like anything else, they should be used appropriately, and the programmer should always be prepared to incorporate some original thought into his design, as well.

Answer 6

Patterns are the problem if they aren't a solution. By that I mean: if a pattern is introduced for the pattern's sake and not to solve a real, existing design problem in the application, it's likely to cause issues rather than solve or prevent them.
I keep telling people here at work that the Gang of Four book (Design Patterns: Elements of Reusable Object-Oriented Software) is a reference, not a handbook for good design.