This could have been an interesting contribution, which is why it is too bad you chose to end it with an inaccurate and rude insinuation.

I maintain that there are good design patterns in any language. My point us that some are more universally helpful and that some languages are prone to needing complex solutions to simple problems. This doesn’t seem to contradict what you point out.

It seems it would have been better to title this article “The problem with pattern-prone languages.”

Therefore, *all* programming problems can be seen as problems with a programming language, since all problems *could* be solved at the language level. In the real world, we have to be pragmatic and use the flawed languages that we have available. These *all* have recurring problems, which result in recurring solutions. These solutions are then generalised into design patterns, which are applicable across various languages that share similar features, but certainly do *not* apply universally.

I’m pretty sure this is explained in the first few chapters of the GOF design patterns book, but since you seem to think it was based around the problems with Java (when, IIRC, it used C++ and Smalltalk), I’m guessing that you never actually read it?

Yeah, I can see where my examples could have been better. This is a useful critique to improve my argument. Thanks for taking the time to explain where you’re coming from.

keithb:

Good points here. Especially about Flyweight: never thought of it that way.

I definitely agree that there are patterns in every language. I’m being careful not to suggest that there are no “real” patterns, or that all patterns are in some way “bad.” My point is a weaker statement: That some languages have more of them because of how inflexible the language is. In that case, you get many, many patterns, some of them solving fairly simple problems.

It is also worth considering the difference between patterns that exist because of a lack of a feature and patterns that exist because of a constraint. I personally believe that languages should be simple, elegent, and flexible. I’m not much for “features”, at least not the type that can’t be expressed as macros or libraries. I suppose any pattern can be obsoleted by adding features, but more interesting are the ones that can be obsoleted by removing constraints.

Note that “Design Patterns: A Smalltalk Companion” exists and that it devotes 14 pages to Factory Method. I have a subtle disagreement with Ramon: in Smalltalk programming it’s not that Factory is unnecessary, it’s that it’s ubiquitous. Not that Smalltalk doesn’t require you to add utility creation methods to a class class, but almost all programmers do almost all the time.

It think that what you are trying to do, identify patterns that are more interesting because they are not so much a work-around for missing language features is an interesting approach—and greatly more sophisticated that the average “critique” of patterns. And yet, would Flyweight seem so interesting in a language with symbols and automatic memoisation?

Or, consider that one collection of Smalltalk patterns contains a write–up of “Abstract Class”, which would be irrelevant, or be invisible or whatever dismissive adjective you like if only Smalltalk had…abstract classes! As it is invisible in Java.

I submit that there are patterns of use in every language, because no language has every kind of way of organising code built in. Even in the languages with a culture of programming extending the language we still find repeating idioms that by convention are not (for example) captured as a macro.

‘I guess if you take it just to mean “a method intended to create and return a new object” you’re not limiting yourself to any particular purpose. The definition I was addressing is “Using methods to abstract away the concrete class of the constructed object.”’

Those two sentences mean virtually the same thing. The sole purpose of extracting new object creation into another method is to hide the concrete class, you wouldn’t do it otherwise. Of course it’s just taking advantage of inheritance, that’s a huge part of what OO is, and that knowledge wasn’t generally accessible to most people prior to the design patterns book, it popularized a common vocabulary for object models that helped make OO widely known.

You are right about some of the patterns being unnecessary in other languages, but you chose bad examples. Both factory method and command patterns are widely used in languages that you can’t say lack the right features.

A better example would have been the factory pattern itself, it’s generally only useful in languages lacking *real* meta-classes. In Ruby or Smalltalk, you’d use the class itself as the factory for its instances and you can add methods to it, and pass it around, classes are real objects, making factories unnecessary. Or the strategy pattern, which is really just a way to fake anonymous methods for specializing higher order functions.

It is certainly confusing that there is supposedly a “Factory Method” pattern and a “Factory Pattern” and all these different takes on it. I guess if you take it just to mean “a method intended to create and return a new object” you’re not limiting yourself to any particular purpose. The definition I was addressing is “Using methods to abstract away the concrete class of the constructed object.” The pattern is the goal and the technique.

As for the command pattern: You say it right when you say it is “trying to emulate a closure.” You don’t try to emulate these in languages that support them natively. That is what I’m trying to get at. You’re working around something your language doesn’t do.

As for design patterns for Smalltalk: I think if the pattern makes sense for Smalltalk it probably does stand a better chance of being truly interesting. Smalltalk is a fine language that doesn’t have a lot of Java’s problems. Some design patterns applicable in Java are not applicable in Smalltalk for that very reason.

The point of the factory pattern is to provide overridable hooks so subclasses can inject different concrete classes into the superclass’s algorithms. I might subclass UIComponent and override the renderingCanvas method to return my own custom canvas that draws things how I like. The point really is to not have naked class references in the middle of methods anywhere because that’s not very flexible; extracting naked class references into a separate method gives the *option* of overriding it to future subclassers who may want to do things differently.

The command pattern is also not just trying to emulate functions in languages that lack them. It’s trying to emulate a closure, a function with state. A closure is an object with one function and an object with one function is closure. This is important because you want to be able to serialize commands. A database transaction log is a good example, a sequence of commands serialized to disk that when replayed in that same order later will rebuild the state back to the point the crash occurred. You can’t do that with just functions, you need closures/objects.

Half the examples in the design patterns book were written in Smalltalk, a language which suffers none of Java’s silly restrictions. What they are however, is patterns for object oriented languages, so they may not apply if functional/procedural programming is your thing.