December 07, 2003
MVC Gentrification
There's been a thread in comp.object about refactoring to MVC. The intent is to tame a purported Swing UI monstrosity, and instead to move towards MVC by-the-Hoyle.
Hmm. I'd have scored Swing as being well within the broad outlines of MVCs intent penumbra, if not umbra, already.
The broader, more interesting question is why the Swing solution is regarded as a Frankenstein. Those components mesh better than most I've seen. Swing is a modern, third-generation (nth?) design / architecture. If programmers regard it as hopelessly Byzantine, what hope is there left? What's the problem with Swing? Is it so broad that its hard to learn? This could be so. My experience with it has been the learning curve is something well short of gentle. Issues like layout intrude far to early for my taste. Few components work out of the box. Is it capriciously arbitrary? Is it that the elements integrate in something short of a "seamless" fashion? They do seem to demand arbitrary trowel work, and more mortar, than one would expect of a framework that aspires to being the substrate for pre-fab solutions.
Is the problem that Swing had to be rolled out essentially finished? It had to emerge full-grown. Many species bear young that have to fend for themselves. Few that engage in the quality side of the quality vs. quantity trade-off abandon them. Yet, being bound to your mistakes as soon as you publish an API really really does constrain evolution. It's team players vs. defectors, as always, once again. How do we avoid the lumbering pageant of slow, coarse grained growth / expansion / dominance and extinction?
The picture to the right is of Tryve Reenskaug, who built the first implementation of MVC at Xerox PARC during the early '80s. (The picture was taken by yours truly at JAOO 2003, in Aarhus, Denmark last September.)
Danny Dig, of UIUC's DCS, gave a nice presentation on the history of this pattern complex / compound pattern / architecture on the same day that Ralph Johnson braved the Big Ball of Mud quagmire. He accurately chronciled the trend towards closer coupling between Views and Controllers, and the ascendance of Mediator objects that buffer the relationships between Views and Domain objects.
The more intimate relationships between Views and Controllers has been driven in part by the absorption of input event generation facilities into the operating system, and its attendant low-level I/O facilities. The more refined divisions of labor among Views, Domain Objects, and the intervening Model / Adapter / Mediator / Mediaptors has been driven in part by the desire for GUI independence, and in part by the rise of automatic GUI code generation tools. Given this, designers are forced to foist their components on the world, ready or not. They must be treated as mature, full-grown artifacts before they are refined in the crucible of full-scale deployment.
