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

Answer 1

Yes, pg is right there. If you see similar code throughout your application, it means that you are missing an abstraction of that code. Less code is better.

Here is another article on the subject: http://blog.plover.com/prog/design-patterns.html

Answer 2

[sigh] How many rants against good practices do we have to debunk before people start using their own judgement?

Short answer: if you're doing real work in an object-oriented language, there's a very high probability that you have implemented some of the GoF design patterns to get the job done. Whether you realize you've done this or not is a matter of education, perspective, and introspection. Denying that you've ever done this or that patterns don't exist or aren't "necessary" or are "overused" is ridiculous - unless you never write anything more complex than 'hello world' ;-)

Why, just the other day i had to implement a visitor facade for a singleton just to get the adapter strategy to work :-P

Answer 3

I think Paul Graham is missing the mark big time on this one. Using patterns isn't about picking up a book that lists them and applying some of them to your code. I would agree that would be a poor choice but that's not what patterns are about.

Design patterns are simply a way of recognizing "Hey, I recognize that this is similar to another problem I've solved before" and learning to create a good abstraction of the solution so it is applicable in appropriate situations.

In fact, odds are, if you've programmed anything of any reasonable size, you've used commonly known design patterns and just didn't know there was a name for it. For example, I was using the "factory" pattern for a long time before I had any clue it was a "factory." Knowing what it's called officially just prevents me from reinventing the wheel again.

Sure some well known patterns are a bit crappy; singleton is definitely suspect. But that one was a clear cut case of a overly clever solution looking for a problem to solve and not doing it very well. But that's why you can find a lot of literature both for and against it—because people recognize it may not be a good solution.

But patterns as a whole are a very good thing, if anything they encourage abstraction.

Answer 4

Design Patterns are defined as the following (from wikipedia but I have read the same in some book too )

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

If you look at applying patterns right from the offset without getting into the problem domain extensively can lead to problems. Use design patterns as a guide or more so as a tip/hint to solve a problem. Forcefully applied design pattern will surely not give a solution thats abstract enough. It is often seen that in Enterprise software a variant or a combination of a few design patterns are used..kind of hybrids. If you say you have never used design patterns then you would be happy to know that something like a foreach loop is actually an interator pattern and you can hunt for more obvious implementations near you!

Answer 5

The term Design Patterns is overloaded and confusing.

There is a narrow way to think of it: basically as a collective name for the OO concepts listed in the GoF book, e.g., Singleton, Facade, Strategy. You probably use this definition if you put Design Patterns as a competence on your CV.

One project can easily contain dozens of singleton objects. This pattern pretty obviously benefits from being coded as an instantiable abstraction, e.g., as a macro or abstract class. Likewise for many of the other patterns in the GoF book.

It seems to me that Paul Graham's thesis is: design patterns, being standard ways to repeat yourself, should be codified as instantiable abstractions, and by corollary you should use a language that has a very flexible way to define instantiable abstraction.

But the concept is more general — I think he misrepresents design patterns. Christopher Alexander invented the concept in order to apply it to the design of countries, cities, towns, and houses. Game designers have languages of patterns like Fog-of-War, Asymmetrical-Abilities, and so on.

In this general sense, it becomes much less obvious that design patterns should all be coded as instantiable abstractions.

If you haven't read A Pattern Language, check out the scope of it here. Imagine something like that for the world of software. The GoF patterns would be way down at the bottom of the ToC: they are implementation details.

What other patterns could you find above them?

I guess one chapter would have game-related patterns. It could incorporate both game design patterns and implementation techniques, — and I submit that this is not a clear-cut distinction —, like the Game Loop, the World Entity, the Spatial Hash, the Height-Map Landscape, and so on. These are all design patterns.

Now, in the scope of one game project, you will probably only have one World Entity implementation. Anyone working in any language would have the sense to make this World Entity an instantiable abstraction like a base class.

But what the pattern describes is how this abstraction is formed: it contains some notion of position, it is renderable, and so on. It's not obvious whether this Design Pattern would benefit from being coded as a macro or abstract class in itself — the pattern already describes an abstraction! Would you make a metaclass for world entity implementations? A macro for defining world entity classes, with all kinds of ungodly parameters?

Looking further up the imaginary Table of Contents, we see that these patterns are subordinate to a more general pattern, that of the Game. Is this worth coding as a macro or abstract class? Maybe. But not obviously. We're talking about a game framework, where you define a computer game by passing parameters, filling in the blanks, etc. That could be productive and fun, but it's not the only way to do things.

The Erlang platform has instantiable abstractions for patterns as general as the Server, which is cool. And I guess an Erlang project has as many Servers as a Java project has Singletons.

But for your specific purposes, if you're working in Lisp, or Haskell, or whatever, and writing a server, sometimes it's enough to just follow the Server pattern, implementing it as good old functions and objects, without trying to make an instantiable abstraction of the whole thing.

All design patterns are not low-level textual patterns in your source code.

Answer 6

I believe this part from Paul Graham's quote is important:

[...] I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write [...]

It shows that if you can build these abstractions in your language (and you can do pretty much anything with Lisp, which is what he probably has in mind saying the above), you don't need to model them with patterns.

But not everybody uses Lisp, so you will only be able to build abstractions where you can, and use patterns where you can't. As an example, in languages without higher-order functions, these are often modeled using the strategy pattern.

It seems to be a matter of how you look at it: the pattern can be seen as a symptom of a problem (e.g. the lack of higher-order functions), or as a solution of the problem (e.g. making something like higher-order functions possible via the strategy pattern).