Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I've started reading the design pattern book by the GoF. Some patterns seem very similar with only minor conceptual differences.

Do you think out of the many patterns some are unnecessary in a dynamic language like Python (e.g. because they are substituted by a dynamic feature)?

share
    
Kind of an interesting question, since it implies that language choice can effectively substitute for code constructs. –  joshin4colours Jul 24 '12 at 21:11
2  
Not an answer, but relevant - I thought the GoF design patterns were as relevant for some general principles that can be distilled out of them as for the specific patterns. I don't mean the idea of a pattern (though that's certainly significant), but more the permission to use classes in certain ways that violate naive OOP principles. For example, there's plenty of patterns where "the shape" quite clearly does not "draw itself", or at least delegates some aspect of the job to some other object. I think that lesson is important in any language that supports OOP. –  Steve314 Jul 29 '12 at 19:19
    
Very interesting question. I wish I could +5 instead of +1. –  MathAttack Aug 2 '12 at 11:27
    
Glance aslo at Are Design Patterns Missing Language Features and Design Patterns Are Missing Language Features over at c2. Its not even a 'dynamic language' issue. The simplest example is the iterator pattern which is trivial in python, perl (and even Java - not dynamic). –  MichaelT Oct 17 '12 at 14:30

8 Answers 8

up vote 59 down vote accepted

Peter Norvig demonstrates that 16 out of the 23 design patterns found in the GOF book are invisible or simpler in dynamic languages (he focuses on Lisp and Dylan).

Since you mentioned Python, there is a nice presentation by Alex Martelli about the topic. Also related with Python, there is a nice blog post demonstrating six design patterns in idiomatic Python.

I also keep a github repository with implementations (by other people) of the most common design patterns in Python.

share
    
Great! That would be a spot on answer :) I wished everyone had grasped the question that clearly. –  Gerenuk Jul 25 '12 at 8:55
2  
According to Norvig, 2 of the 16 (Interpreter and Iterator) are "either invisible or simpler" due to macros (which Python doesn't have). –  mjs Jul 29 '12 at 21:19
1  
its not clear to me that all these patterns aren't need because lisp is dynamic but rather because of other features such as being a strong functional language –  jk. Oct 10 '12 at 14:20
    
@mjs Iterators are a builtin feature of Python. –  faif Oct 15 '13 at 10:03
    
@faif Norvig's paper was written in 1996, before Python had iterators. (It seems they arrived in version 2.1 python.org/dev/peps/pep-0234/.) –  mjs Oct 15 '13 at 11:02

The only one that comes to mind is the Singleton pattern.

Since Python doesn't force you to use classes for everything, you can just use a global data structure instead. That global data structure could be managed by an instance, but you do not have to control the instantiation of that class, you just create the instance on import and leave it at that.

Mostly, Singletons in python are replaced with a module. Modules in python are by their very nature Singletons; the python interpreter creates these once and once only.

All other patterns in Design Patters I've used in Python at one time or another, and you'll find examples of them throughout the Python standard library and in Python itself.

share
1  
Isn't that actually an anti-pattern these days? –  Den Jul 24 '12 at 8:00
11  
The Singleton is an antipattern. In all languages. It was created to solve several unrelated problem and is not a good match for either (note, that even Java has static members, that exist once per class, so you don't need an instance for that). –  Jan Hudec Jul 24 '12 at 8:00
1  
And in Python we never bothered with it as there never was a problem to solve. –  Martijn Pieters Jul 24 '12 at 8:12
1  
"Python doesn't force you to use objects for everything" Not true. It's just not obnoxious as in Java, but still, in Python everything is an object. Even module is an object. –  vartec Jul 24 '12 at 10:37
2  
@Darthfett: I am well aware of how len works; Guido made an explicit choice here. My point is to show that Python is not a pure OOP language; it is a pragmatic language. I like it that way. –  Martijn Pieters Jul 24 '12 at 14:58

Design patterns are for the programmer, not for the language. Programmers tend to use patterns that help them make sense of the problem at hand. No design pattern is strictly necessary, but it may be of use to help simplify what you're trying to do.

Python, and duck typing specifically, does provide an end around a lot of common patterns and practices, and a lot of the restrictions imposted by some patterns (privacy, immutability, etc) only hold to the extent that the programmer agrees not to break them. But still, they do work as long as the programmer plays along. A door is still a door, even if it's framed by imaginary walls.

Python is considered a "multi-paradigm" language; you can use whatever patterns you want. This is intentional. It provides for complex class hierarchies, for example, even though they're completely unnecessary and a bit artificial. But for some people that particular abstraction is helpful. Not because the problem demands it, but because the programmer does. So there you go.

share
    
That's certainly interesting. So which patterns in particular do you mean that one might forget about, because there are better ways in Python? –  Gerenuk Jul 24 '12 at 8:49

No design patterns are necessary. In any language.

I tend to come across a lot of code written by people who read up on design patterns and than think they should use them all over the place and the result is the actual code gets buried under tons of interfaces, wrappers and layers and pretty hard to read. That's a wrong approach to design patterns.

Design patterns exist so that you have a repertoire of useful idioms handy when you come across a problem. But you should never apply any pattern before you identify the problem. Keep It Simple Stupid should always be the superior governing principle.

It also helps to think of design patterns as a concept to think about the problem rather than specific boilerplate code to write. And about much of the boilerplate as workaround to Java lacking free functions and standard function objects that you use in most other languages that have them (like Python, C#, C++ etc).

I might say that I have a visitor pattern, but in any language with first class functions it will be just function taking function. Instead of factory class I usually have just factory function. I might say I have interface, but than it's just a couple of methods marked with comment, because there wouldn't be any other implementation (of course in python interface is always just comment, because it's duck-typed). I still speak of the code as using the pattern, because it's useful way to think about it, but don't actually type in all the stuff until I really need it.

So learn all the patterns as concepts. And forget the specific implementations. The implementation varies, and should vary, in real world even in Java.

share
21  
Your opening statement is oversimplifying to the extreme. It is true that patterns have their cost, so shouldn't be used blindly, just for the sake of it. But in the right place, they can be a great help. And yes, they are language specific - some patterns are unnecessary in some languages because the language itself supports a better approach. But that is still pretty far from your opening claim. –  Péter Török Jul 24 '12 at 8:39
2  
Btw Visitor is not entirely replaced by higher order functions - it is a solution to implement double dispatch in a language which doesn't natively support it (such as C# and C++). (And it should indeed be used very sparingly - I consider it one of the most arcane and costly patterns whose usage is IMHO so hard to justify that I myself have never used it up to now.) –  Péter Török Jul 24 '12 at 8:44
10  
Well, you never need a pattern. What you need is to solve a problem. If you don't know any pattern for it, you can still solve it, it will take more thinking and you may come up with a solution that matches some pattern or one that does not. Knowing the patterns just makes it easier. –  Jan Hudec Jul 24 '12 at 9:18
3  
@Gerenuk: Yes, but the point is, that the patterns are not language-specific, they are for your head. You often find that some pattern is realized much more easily and using different tools in python, but the same concept usually exists. –  Jan Hudec Jul 24 '12 at 9:23
4  
@PéterTörök: Visitor is not replaced by anything. The point is the same concept might be implemented using different tools in different cases, but I still consider it the same pattern. –  Jan Hudec Jul 24 '12 at 9:25

Design patterns are ways of solving particular problems. If a problem is not met, pattern of resolving it has no use.

People are trying to adapt design patterns everywhere as if it was a best practice to have design patterns in your project. That's other way around. You encounter a problem that can be solved with a factory pattern? Cool. Adapt it. Don't look up your code and try to find the right place to implement a singleton (or factory, or facade, or whatever ...).

Perhaps Python has its own design patterns not available for Java and .NET people (due to nature of these languages)?

share

Abstract factory pattern is unnecessary in duck-typed language such as Python, as it's practically built into the language.

share
8  
well, you still need different factories. You just don't need the interface definition. –  Stefano Borini Jul 24 '12 at 14:26

The original "Design Patterns" book documented and named some common idioms useful in imperative, object-oriented languages such as C++ and Smalltalk. But Smalltalk is a dynamically typed language, so it can't be strictly a matter of being dynamic.

However, the answer to your question is still "yes": some of these design patterns will be irrelevant to modern dynamically typed languages. More generally, there will be different design patterns in different languages, especially in different kinds of languages.

To reiterate: a "design pattern" is simply a name for a programming idiom: a common solution to a frequently encountered problem. Different languages require different idioms, because what is a problem for one language may be trivial for another. In this sense, design patterns tend to point out weaknesses in the languages they apply to.

So, you might look for other features which make modern dynamic languages (or ancient ones like Lisp) more powerful, rendering some of these classic design patterns irrelevant.

share

I would say that patterns are always language dependent. That most python patterns look like those defined in GoF it's because of the OOP of Python, that being said OOP is not like OOP (no two languages define objects and their manipulation 100% alike).

So there's no doubt some patterns will not be applicable "as is", some might make no sense and there are some patterns that might be only be meaningful to Python.

To get back exactly at your question: Patterns are only necessary if you need them. You don't have to use them if there's no need for them (as Jan Hudec already said).

Furthermore, there are much more patterns than those mentioned in GoF. See in wikipedia other patterns

share

This site is currently not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .