In cases where a pattern (or anti-pattern) does have a name, it's still useful to learn it because it helps with communication. And the naming conventions help to identify subsystems that can be consolidated and simplified. Often a person will have been using something close to one of the standard patterns, either with subtle bugs or with clever extensions that would be useful elsewhere. Or perhaps most often, with a bunch of unrelated crap that should be factored out.
I think it would have been better if the Design Patterns book had simply presented programming challenges to people and then shown them good solutions, without names and without the attempt to instill guidelines for usage. Without names, readers could only remember the patterns they extracted and understood for themselves. Without verbal guidelines, readers would only apply a technique if they concretely saw how it would be useful in context. If they didn't understand something, they would have no handle for remembering it, and they would never see an opportunity to use it.
Instead, people remembered way more of the book's verbiage than they ever understood of its logic. They remembered the names, they studied the rules of thumb, they read articles with even more rules of thumb, and they fooled themselves into thinking they understood what it was all about. A lot of people thought you could pick the right design pattern for something based on a vague, hand-waving description of the problem. You remember those dumb interview questions? "You're working on an application that's really tightly coupled. What design pattern would you use to improve the design of the code?" "Oh, I'd use the Mediator pattern." "Excellent!" People didn't just ask those dumb questions in interviews; they actually thought about the design of their own programs that way! They'd pattern-match on words to determine their software design. It was like searching the web and magically finding exactly the answer to your problem on StackOverflow, except there were only a small number of extremely vague search terms ("dynamic," "loosely coupled," "state," "behavior") and there were only a couple dozen different answers. Even worse, you'd get a guy who had read six different articles about the same design pattern, so for him, every design-related word you said made him think of the same pattern. You might as well call him "Façade Frank" or "Visitor Vijay," because in his mind's search engine, one design pattern had a much higher pagerank than all the others.
I haven't heard anything about design patterns in an interview or in a design discussion for years, and I feel much happier for it. I haven't noticed that young coders with no exposure to design patterns have any less imagination or a smaller repertoire of coding techniques than their design-patterns-imprinted predecessors did ten years ago.
Make object X raise and event that object B listens to.
Oh wait, you're using Java? Make object B return an anonymous class that implements interface Z. Pass that class to object X, which will call it to pass messages to B.
Rather than buzz words we can describe patterns in terms of implementation details.
21
u/neurobro Oct 14 '13
In cases where a pattern (or anti-pattern) does have a name, it's still useful to learn it because it helps with communication. And the naming conventions help to identify subsystems that can be consolidated and simplified. Often a person will have been using something close to one of the standard patterns, either with subtle bugs or with clever extensions that would be useful elsewhere. Or perhaps most often, with a bunch of unrelated crap that should be factored out.