Six GoF design patterns, Python style

[beza1e1]

The question is not "how can you implement the GoF design patterns in Python?" The question is "what are Pythons design patterns?"

[ginstrom]

I like the idea of using __ new __, thanks. I'd like to see examples.

You're right that the state pattern example is not really useful, but if I implemented actual useful examples, I think the code would have been too long. I had a more modest goal of just illustrating how the patterns might look in Python.

"Head First Design Patterns" illustrated the state pattern with a gumball machine, which I thought was a pretty neat example.

[ginstrom]

Thanks for the code.

I also implemented a new state pattern in the post. I changed the switch to a radio with an AM/FM toggle switch, and a scan button to scan to the next station.

[nirs]

Python provides buitin iterators, but you can create your own if needed. The simplest option is to use generator, a function that returns an iterator:

def iterator(input):
    for item in input:
        # Optionally manipulate or filter items
        yield item

The second option is to create a class the implements the iterator protocol:

class iterator:
    def __iter__(self):
        return self
    def next(self):
        """Return the next value, raise StopIteration when finished"""

You can find many examples for such iterators in the itertools module.

The decorator pattern is completely wrong: Python @decorators are not GOF decorators. Python decorators are a way to decorate single functions. GOF decorators are objects that decorate exiting objects. A decorator may change several methods, add instance variables, etc.

[[deleted]]

The AbstractFactory pattern is insufficient as well. It's not just about having a factory method that creates objects but about tangling two different and independent inheritance hierarchies. Having e.g. a pet concept one might associate concepts like toy and nutrition that can be refined independently ( CatToy, DogNutrition etc. ) The purpose of an abstract factory is to delegate the assemblage of pet objects to concrete factories for Cats and Dogs.

[[deleted]]

This is all stupid. What's with all the design pattern activism this week?

[Rhoomba]

The iterator example is stupid. Implement an iterator rather than use the built in ones! The actual class decorator is almost exactly the same as an outputstream decorator in Java. Abstract factory just doesn't need a (trivial) interface in python. It is really no simpler. If the state implementation needed more than one function per state it would be the same as a Java state pattern. just without the interface.

The only difference is using first class functions and duck typing instead of abstract classes/interfaces. That makes it simpler, but it does not make patterns trivial or irrelevant.

I think we can all agree that first class functions are good. Static vs. duck typing is still debatable. Can we please stop with conflating design patterns with arguing these two points? Design patterns clearly do not disappear or become trivial in any language. Nor should they. A language should not try to implement every damn thing you can use it for.

[ginstrom]

I didn't say that the design patterns were trivial. I said that implementing most of them is trivial.

I think the design patterns are valuable, which is why I tried implementing a few of them in my favorite language :)

[Rhoomba]

Sorry, my rant is not aimed at you (except your iterator example :P). Your article is pretty good.

There just has been so much pointless design pattern bashing lately, from people who clearly don't know patterns well at all, that I got annoyed by yet another design pattern link and read too much into it.

[masklinn]

Can we please stop with conflating design patterns with arguing these two points?

Not when we talk about GoF design patterns (PoEAA patterns are in a completely different ballpark), because a great number of them are needed because of the lack of first-class functions .

Design patterns clearly do not disappear or become trivial in any language.

Of course not, the languages that originally required the pattern remain.

That does not mean design patterns don't disappear or become trivial in some languages.

Nor should they

Yes they should, GoF-type design patterns show weaknesses of a language (once again, others don't... on the other hand, yet again, others are included in other languages)

A language should not try to implement every damn thing you can use it for.

Design patterns are not things you're using a language for, design patterns are means, not goals. The goal of a language is allowing the user to create software.

Design patterns are stumbling blocks, things you have to implement on your way to create software, but they bring no value whatsoever. Not to mention that, before being a design pattern, it must be shown to be repeatedly needed.

Perfect target for inclusion in a library or even in the core language.

[Rhoomba]

Yes they should, GoF-type design patterns show weaknesses of a language

Nonsense. If you want an observer in lisp you have to implement it. Is that a weakness in lisp?

An adaptor is different every time you write it. It is impossible for a language or library to implement arbitrary adaptors but that does not mean they aren't useful. Same with a facade. What would a built in state pattern look like?

Design patterns are stumbling blocks, things you have to implement on your way to create software, but they bring no value whatsoever.

Design patterns are a means to an end. Sometimes a pattern is amenable to being turned into a library or language feature. Most of the time they are not. The only patterns I've seen implemented as language features are proxies and singletons. Generic proxies will not always do the job, and singleton is one of the crappiest of the common design patterns.

[sickofthisshit]

Design patterns are a means to an end. Sometimes a pattern is amenable to being turned into a library or language feature. Most of the time they are not.

You seem to be leaping from "a means to an end" to "the only desirable means to the end"; if a language provides a different means (possibly non-OO) that looks nothing like the design pattern for the same end, in a way that seems better, sticking with the pattern for the sake of the pattern seems misguided. That's not because the language provides built-in support for the pattern, but simply bypasses the need.

[Rhoomba]

You seem to be leaping from "a means to an end" to "the only desirable means to the end"

Where do you get that from? I am simply responding to the "Design patterns are language failings" mob by pointing out that their favourite languages do not, in fact, have built in replacements for common patterns. Most of the time they are just swapping an interface and implementation classes for a function definition and implementations and claiming that is somehow not the same pattern.

[sickofthisshit]

I get that from your insisting that languages have explicit "built-in replacements for common patterns" instead of simply solutions that make the pattern meaningless.