Alternatively, if you think of the patterns not as names of things, but as the actual solutions presented in the design patterns book, none of them. None of the

Alternatively, if you think of the patterns not as names of things, but as the actual solutions presented in the design patterns book, none of them. None of them can be implemented in a non-class language when all the patterns are intrinsically class oriented, and quite heavily so, often actually dependent on inheritance. Not saying this is the only way of viewing them; there is validity to both but it is I think it is important to keep in mind that the patterns are also supposed to be solutions and not just the names of problems. What happens as you move around languages is not so much a binary thing, but the relative importance of them changes. Plus you should expect patterns to appear in a new language that weren't in the old language, both because the pattern would be too easy to be a pattern and too difficult to be a pattern. Some will fade away so far that maybe they aren't useful any more. I really know someone doesn't get the GoF pattern thing when I see "Design Patterns in X" for X != ["Scheme", "C++"] and they are exactly and only the GoF design patterns, implemented in the target language. That is not what they are for. Generally in my experience they're some combination of "wrong", "unidiomatic", and "not the easiest alternative" in the target language anyhow.