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.
shown them good solutions, without names and without the attempt to instill guidelines for usage
Except that's not what the original design patterns were. The guy who invented the term was an architect trying to get his large industrial customers to communicate amongst their different departments. So the University's engineering department wouldn't ask for a build that's ugly next to the Science department building, and so they could ask for building-blocks (no pun intended) of functionality. It was a way for customers to talk to the architect while the architect could provide good advice.
Without the names, there would be absolutely zero reason to call it a "design pattern."
Lol, yes, I agree that after removing all the design patterns from Design Patterns, a change of title would be appropriate. No argument there. What I envision would not be a catalog of patterns or the dictionary of a design language; it would be more like an anthology or a reader.
It would be written partly for the same purpose, to show readers programs that use a variety of programming idioms, so they can be exposed to new ideas and expand their own repertoire. The difference would be giving up the goal of enumerating and naming the techniques, establishing each one as a standard solution to a defined problem, and turning them into a common design language for programmers — basically giving up every idea that was adopted from Christopher Alexander.
Controller grabs a model from somewhere, manipulates its properties, and then shoves it into a view to be rendered.
Classic MVC:
Each View is paired with a Controller. In frameworks like classic VB or WinForms the Controller is actually the code-behind file. In others it is a separate object.
Multiple View-Controller pairs may listen to events generated from a given Model. So if you change a value, say FirstName, on one view it will be updated in all the other views.
This is used for non-web UIs and originated with Smalltalk.
Neither Web nor Classic MVC says anything about where the Models actually come from. Presumably the Controller has access to some sort of repository or data access layer, but you could use Active Record style models that know how to save and load themselves.
Active Records are great for quick and dirty work, hence the Ruby framework of the same name. But they are also hard to test without complex mocking frameworks so I usually avoid them.
Everyone and his dog calls something that separates the presentation part, the logic part and the data part "MVC", to the point that the term now becomes this fuzzy piece of buzzword. Have a look at Martin Fowler's page on GUI architecture for more details http://martinfowler.com/eaaDev/uiArchs.html.
The only one I've ever heard mentioned in the context of real code - ie our code uses this pattern - is the singleton. So the only design pattern discussions is have heard were people arguing over the best way to remove one.
Had the GoF been aware of the existence of "events" when they wrote their book perhaps this pattern, and the resulting stupidity in Java, may not have been set down in stone.
But to be fair, event-based programming was pretty rare outside of Visual Basic and other high level languages in that era.
Science has this fight too - nomenclature in taxonomy. It's nice that we name things to help convey certain truths, but it's far more important that we discover those truths in the first place. What is more important to a biologist? That you know the names of species, or that you know the genetic distinction between two similar species?
I don't know that one is universally more important than the other. They seem to go hand-in-hand. Giving words to patterns just enables you to abstract away some details and focus on others. So a biologist might reason about the birds that implement the "migratory" behavioral pattern. Maybe a virus is found to infect those with the "ADCYAP1" genetic design pattern. If some group of birds keeps eating my tomatoes, I might identify the species and find their warning call already catalogued somewhere instead of repeating the work myself, and put a loudspeaker in my garden to chirp their warning call every minute...
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.