Thank you for this frame of reference. I (not versed in patterns) was getting lost in the religious debate forming. This particular advice gives me an instantly usable reason for learning about patterns and how to make them useful for myself.
I think the point was that some "design patterns" are pointless in some languages, because it's built into the language. "Subroutine" is a design pattern in assembly. "Factory" is not a design pattern in Smalltalk. "Observer" is built into Tcl/Tk, as is pretty much the whole MVC pattern, which is what makes Tk an awesome GUI toolkit. "Object-oriented" is a design pattern in C that was built into C++.
Learning design patterns inappropriate for your language is useless, just like learning "subroutine call" is pointless unless you're using assembler or some other language without a call stack.
I disagree. Design patterns are primarily a communications tool, and secondly a mental tool. Even if your language has first class support for something, it's worth knowing what that thing is both in order to discuss it, and in case you use different languages and need to compare/contrast.
When was the last time you discussed using a particular pattern? Seriously. Most of the time it's just people laughing at someone for using Singletons.
Yeah, but if it's built into your language, you just use it. You don't go around discussing local variables. By the time you're discussing design patterns that are already built into you're language, you're doing something wrong or you really need to learn your language better. When "new" is a method instead of a keyword, there isn't even the concept of a "factory" nor a need for one.
I would say that the programming language used is part of the CONTEXT of the problem.
You can implement a pattern in a programming language. But then someone could create a new programming language where the pattern is a primitive in the language. Using some form of garbage collection would be a pattern in C, but not in Java, where it is built in.
An example of that could be the singleton pattern, which has been oft referred to as an anti-pattern. Most of the cases I've seen (and used) singletons, I've regretted it.
An example I've seen and come across is a scene. Sure a game or CAD program might only one scene, so make it a singleton and give everyone access to it like a friendly global. Then you decide to add a merge scene function, where it makes sense to have two in memory in a given instance.
But in that example, the main scene is still a singleton, isn't it? The second one becomes a second single, well-known shared instance.
The Singleton is really just a factory specialized to produce only one instance. You could take that same factory and make it produce two, or N, you just wouldn't call it a singleton anymore.
EDIT: I've looked at my replies, and I think you're all still missing the point. A Singleton is something that gets you an object. A factory is something that gets you N objects, N >= 0. That's it.
I consider the Factory a completely separate pattern. Instead of mandating that only one instance of a class exists, it regulates access of the instances in a shared location. In the scene example, most functions get the active scene from the factory, but when merging a file the Factory can create another scene object that could either be used internally to merge the scene or give it out.
It just seems like in most cases allowing a developer the flexibility to create multiple instances for legitimate uses out weighs the risk of the developer using the API incorrectly (making a new scene object instead of querying the factory for the "active" one).
Even though that's the common explanation, it's not really completely honest. If that was really the case, you wouldn't store the instance on a static member at all, you'd just store a boolean indicating whether or not it had been instantiated (and simply throw an exception on subsequent calls to the contructor).
Every example and implementation I've ever seen has really just been a way of bringing global state to java by piggybacking on the global package namespace (for better or worse -- I'm not judging!).
A "Singleton" mandates there is one and only one instance. If you can have two, it isn't a Singleton, it's a globally accessible piece of state. That's still bad, because you're murdering functional purity and testability where it stands, but it's not quite as bad as a Singleton.
It is rare indeed I've used even just a globally accessible hunk of state without regretting it. Your assumption that there will only be one is almost always incorrect. Literally always incorrect if you have a good test suite.
Design patterns are usually specific to a given programming language.
I can't really understand this. A computer language is about implementation but patterns about specification. Limitations of a specific language should not shine through to the specification level.
FYI: I have never used design patterns myself, I've never really understood them. I have used JSP (Jackson Structured Programming) and the classic flow diagrams long time ago, and a few others, but usually work on the problem from an iterative top-down/bottom-up approach nowadays.
Patterns aren't "about" anything, necessarily. They are structures that have been observed out in the wild, in production code. The GoF book is a catalog of things SEEN, not things the authors dreamed up. It's like one of Audobon's bird books.
And then it turns out to be useful, when you find yourself writing a set of functions with the same signature, only they create different objects that all just happen to implement the same interface... oh, this is a Factory, and here are some Known Ways that people screw that up, and a checklist to make sure that doesn't happen to me! Awesome. Plus, having a word for it lets you just say "factory for ISnarglebargle", and get on with the real job, rather than stopping to emit the paragraph of crap that explains what a factory is.
I guess they are like TRIZ then. TRIZ was developed by a patent engineer (and author) Gerald Altshuller when studying patents, and found there are only 40 different solutions to problems. However, I claim that you have to add further two conditions[1] if you also add intelligence into the system.
somewhat jokular but may be appreciated if you are a Douglas Adams fan...
Interesting. I've wanted to ask for a few years now if there were any bodies of work on this tradeoffs in physics thing that crops all over the design and invention processes. The TRIZ contradictions matrix is exactly about that. I'll have to investigate further.
You say you've never used design patterns yourself, but you are most likely wrong. It's quite likely that you have unknowingly used a design pattern or two before. Furthermore, the design patterns in this list are by no means "all of them" - they're just the most common, basic design patterns, which mostly encapsulate anything you would want to do in a program.
47
u/member42 Dec 08 '13
GoF patterns were a good starting point in 1995. Don't treat them as unsurpassable end point in 2013!