Are there any design patterns that are unnecessary in dynamic languages like Python?

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)?

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.

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 then think they should use them all over the place. The result is that the actual code gets buried under tons of interfaces, wrappers and layers and is 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 a function taking a function. Instead of factory class I usually have just a factory function. I might say I have an interface, but then it’s just a couple of methods marked with comments, because there wouldn’t be any other implementation (of course in python an interface is always just comments, because it’s duck-typed). I still speak of the code as using the pattern, because it’s a 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 the real world, even just in Java.

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

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.

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.

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.

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)?

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

Filed under: softwareengineering - @ 14:15

Thẻ: design-patterns, python

Thiết kế website giá rẻ

Danh mục

Are there any design patterns that are unnecessary in dynamic languages like Python?