I just read through a blog post by Sho Kuwamoto titled MVC considered harmful, and began typing a comment that quickly became a small essay, so I decided to post it here instead. While I don’t agree with Sho’s idea that MVC is not needed for most RIAs (I think the concepts are valuable for virtually any kind of Flash project, RIAs in particular), I also didn’t agree with some of the more zealous comments about the sanctity of design patterns. Here’s my take on the whole thing…
One of the things I try to emphasize with developers is that the only absolute in programming is that there are no absolutes. A lot of developers get trapped, either by becoming a pattern zealot and wasting a lot of time trying to code to patterns, or by disregarding patterns completely (because they are too hard to understand, require too much forethought, etc).
Patterns are architectural heuristics. Understanding them should widen your solution spectrum, not narrow it. They provide you with proven ways of solving a specific problem in programming. The reality is that you will rarely encounter that specific problem in the wild, but you will encounter variants of that problem – as such you must be flexible enough in your coding “philosophy” to adapt patterns to suit situations. You must code to the scenario, not to the pattern.
Fact: No one codes Flash using pure MVC. Many developers code Flash using variants of MVC, but no one uses a pure implementation – because there is no pure definition anymore. MVC is over 25 years old (1978), and it’s definition has been blurred over time as developers massage it to work with modern application constructs. The most obvious examples of this are the updates to the pattern for Smalltalk in the late 80s and early 90s, then again by the Group of Four in 1995. One of the first things you will realize if you read up on MVC (and patterns in general) is that everyone has a slightly different take on them, and this is a good thing – it means developers are adapting a heuristic to work in their environment.
Patterns also provide a foundation for communication between developers. If a group of developers all share knowledge of MVC, it is far easier to discuss the architecture of an application that implements MVC because a certain structure can be assumed by all participants. One must remember though that it is a foundation, and we can build on it by qualifying our usage of patterns: “This application implements MVC, with the caveat that…”
Flash in particular requires flexibility, because most projects are not your run-of-the-mill form based applications, and patterns often do not apply perfectly (but they certainly DO apply).
In conclusion, understanding of patterns in their pure forms is essential for any modern developer, regardless of the language they are using. This understanding must be tempered by common sense, and willingness to adapt that knowledge to achieve concrete goals. A programmer that understands design patterns is an educated developer, but a smart developer knows how to implement and adapt those patterns to real world situations.
Pattern zealots might sound smart, but they are not much better off than developers without any understanding of patterns at all. Both are narrowing their solution set through their ignorance.
I’ll leave you with a link to a quote from Children of Dune, which I think sums things up nicely.