5

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?

0

2 Answers 2

14

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.

5
  • 4
    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.) Commented Sep 9, 2012 at 8:44
  • @JörgWMittag: Huh. You learn something new every day. Did not know that.
    – pdr
    Commented Sep 9, 2012 at 8:46
  • 3
    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. Commented Sep 9, 2012 at 9:46
  • Well I would not say they are not a design tool - they literally have the word "design" in their name :)
    – Jas
    Commented Jan 4 at 9:07
  • @Jas a Power User doesn't need to be plugged in an outlet.
    – T. Sar
    Commented Jan 6 at 20:30
0

The question is quite old, but to add to the top answer, for anyone still in this topic, besides being a great communication framework, the design patterns are primarily a great tool to ease up the architecture decision-making. I would not agree that they are not a design framework - well they are literally called "Design Patterns" for a reason.

The intended use is for a developer to avoid re-inventing the wheel and recognise a case for using a design pattern, when the need for one is identified. You use them to make your decision making faster, more reliable as well, and in doing so, provided your team is also competent with design patterns, you do also ease up the communication within the team.

Now to answer your question about using the GoF patterns across multiple languages. The answer is that there is no single approach, because Design Patterns are based on Object Oriented Programming. Javascript and Ruby for example, are more functionally-inclined languages (or at least that was the intention). I would advise to learn them well by practising using one language, for example Java and then as you gain foothold and sense of it, try to apply and modify for another language, which may not be purely OOP.

In short: learn by doing, then try to extend.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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