I am referring here to the design patterns found in the GOF book. First, how I see it, there are a few peculiarities to design pattern and knowing multiple languages, for example in Java you really need a singleton but in Python you can do without it you write a module, I saw somewhere a wiki trying to write all GOF patterns for JavaScript and all the entries were empty, I guess because it might be a daunting task to do that adaptation.

If there is someone who is using design patterns and is programming multiple languages supporting the OOP paradigm and can give me a hint on how should I approach design patterns. An approach that might help me in all languages I use(Java, JavaScript, Python, Ruby):

Can I write good application without knowing exactly the GOF design patterns or I might need just some of them which might be crucial and if yes which one, are there alternatives to GOF for specific languages, and should a programmer or a team make their own design patterns set?

1 Answer 1


First thing to understand is that design patterns are not a design tool. They're a communication tool. Can you write a good application without knowing the GOF design patterns? Absolutely. You'll probably find you use design patterns already, you just don't know it. After all, they are common solutions to common problems. But can you tell a colleague how to do something better? Not easily.

Second thing to understand is that some design patterns are so common that they're now built into most modern languages. For example, you don't need an Observer pattern in C#, you have events (which are the Observer pattern, but you never need to say to a C# developer "use an Observer there").

Third thing is that the GoF design patterns book was written several versions of Java many moons ago and was based very much on class-oriented languages. Javascript isn't a class-oriented language, it's a prototype-oriented language, and Python and Ruby are both dynamic. So some of the GoF patterns may be irrelevant to those languages (but some may not).

Much more useful nowadays are the patterns described in Martin Fowler's Patterns of Enterprise Application Architecture.

All this said, it's useful to understand the GoF patterns, if only to facilitate communication with other developers who understand them. The GoF book is dry and hard to get your head around sometimes -- they also make for an interesting thought exercise, they might prompt you to see common patterns in your team's application and write your own patterns. It's also not very precise (when you talk about the difference between Adapter, Proxy and Facade, for example).

There are some good sites out there with much clearer descriptions.

  • 2
    Actually, the GoF book was written all versions of Java ago, Java didn't even exist yet. (More precisely: it was an obscure unreleased research project.) Sep 9, 2012 at 8:44
  • @JörgWMittag: Huh. You learn something new every day. Did not know that.
    – pdr
    Sep 9, 2012 at 8:46
  • 2
    The examples are in C++ and Smalltalk. Unfortunately, some of the Smalltalk examples are, let's say, less than idiomatic, they look more like straight ports of the C++ examples. Some are also rather contrived, you wouldn't use that pattern at all in Smalltalk. (For example, it is said that the Interpreter Design Pattern was only included in the book as a practical joke the Smalltalk community played on the C++ community.) And given the advances in both the C++ language and the understanding of how to "properly" use it, the C++ examples probably aren't very idiomatic either, nowadays. Sep 9, 2012 at 9:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.