From the article “Design Patterns 15 Years Later: An Interview with Erich Gamma, Richard Helm, and Ralph Johnson”
Erich Gamma: Yes, and it is funny that you mention the iPhone. The iPhone SDK is based on the NeXTStep object-oriented frameworks like the AppKit. It already existed when we wrote Design Patterns 15 years ago and was one source of inspiration. We actually refer to this framework in several of our patterns: Adapter, Bridge, Proxy, and Chain of Responsibility.
Richard: Which is a great example of the enduring nature of good design, and how it survives different technical manifestations.
Emphasis mine.
In the Microsoft developer community, we are just now getting around to implementing patterns like MVC, Adapter, and Observer. People still argue over whether or not the MVC pattern is “necessary” to build a “working application”.
I guess it depends on whether or not you like good design?

5 Comments
Oh, gosh! Have you seen WebObjects, NextStep’s web framework? Have you any idea of difference between MVC in reach client and web app? Have you ever wrote a single line of Cocoa?
Adapter and observer is new to Microsoft frameworks? What? It’s even embedded into some of it’s languages. Design patterns are common idioms have not implemented by programming language. Objective C programming language is old and dirty. It had zero progress for an ages. Recently it’ve made some progress but still is as archaic as sabre-toothed tiger.
Those developers went with MVC only because subclass method look-up is way too expansive in ObjC. If you look at any Cocoa app intensively enough, you’ll surly see that Controller class is code class is code-behind – no more. Logic wiring in Cocoa partially done in UI designer and UI logic – in Controller. It’s inevitable. Thit’s the way Cocoa works.
Gamma and others only like Cocoa because of it’s raw dynamic nature – it’s great illustration for patterns, done in other languages using simple one-liner. Besides that ObjC in terminology is derivative from Smalltalk.
Behind? I’d say in many cases they’re moving the state of the art forward. .NET 1.0’s events and delegates were a step forward in implementing Observable/Observer. Now, in .NET 4.0, Erik Meijer’s Reactive Framework basically shows that Observer/Observable and Iterator/Iterable are the same thing. WPF has introduced MVVM, which is a far better pattern for well-designed, modern desktop UI than MVC.
Rafiki – Yes, I’ve written Cocoa before. The logic wiring ( whatever that is) is not done in the view and controller in a properly designed app. In fact, unless you subclass the views and purposefully put logic in your views, it’s impossible to put application logic into your views.
Mark – MVVM is just a re-worded Presentation model. It’s just for branding. I haven’t looked at the Reactive framework, but how long before that makes it into the mass markets hands? Sure some parts of MS Research are pushing the envelope, but most of that stuff will never make it into the BCL.
Oh, yeah, Scott? User interaction handling in MVC should be done in Controller, however Apple evangelizes event wiring using Interface Builder (view designer). Of course you could do that by hand, but designers of framework insist on using IB. On the other hand delegation (and data source) paradigm used by Apple in it’s more complicated view classes forces you to introduce view-specific methods in your controller class. Of course you could do it in a separate class, but Apple do it in controller in it’s documentation and moreover in it’s implementations (TableView and TableViewController in Cocoa Touch).
I’m pretty sure it’s exciting to play with a new (for you) and shiny (in combination with beautiful hardware) thing, but please, please, please, do it correctly and after a bit of thinking (or better research). What did you meant mentioning Observer. Is void* pointer and method name string is superior? Do it in .NET – it’s just silly, but do it if you prefer. Adapter? What about it? How it should be embedded into Framework? MVC? Is good separation of concerns between code-behind file and declarative view is *really* different of Cocoa’s Controller + declarative view scheme?
Scott, I have studied patterns, implemented several and have inherited quite a few applications with patterns implemented. I think the thing you have to recognize is:
1. Will a pattern really “move the needle” for me now?
2. Will the pattern make it easier to support later on?
3. Do I need to be a purist and implement a pattern the way it should be, or the way that works best in this environment?
Some patterns, such as Singleton or Presenter, are classic. Others, like Factory Factory, are just plain stupid and serve no real purpose other than for someone to say that they developed a pattern.
Every bit of your software should follow a pattern, other wise you end up with disconnected chaos. However, that pattern should be yours ultimately, even if it did evolve from some other pattern.
Study them, but leave the purist implementations for academia.
2 Trackbacks/Pingbacks
[...] How far behind are Microsoft developer frameworks in terms of design? (Scott Koon) [...]
Social comments and analytics for this post…
This post was mentioned on Twitter by spoon16: How far behind are Microsoft developer frameworks in terms of design? http://bit.ly/3Td1K...
Post a Comment