This post originated from an RSS feed registered with Java Buzz
by Scott Delap.
Original Post: The MV/C Antipattern
Feed Title: ClientJava.com
Feed URL: http://www.clientjava.com/archives/wireless_mobile.rdf
Feed Description: Client/Desktop Related Java Development
I agree with Benjamin's recommendation of MCV. Writing the model and controller first causes different thought patterns . Normally people have some sort of model, write a view, and then are left scratching their heads with this "controller" asking what it should do besides be a facade to some parts of the model. MCV increases the likelyhood that the view will do as little as possible. This makes testing and swapping out the view representation if needed easier. You are also likely to start seeing patterns in your controllers and models which can be refactored to leverage common code and feature better design.
The MV/C Antipattern MV/C may be more familiar as "MVC," or Model-View-Controller the design pattern used in the Smalltalk environment [KP88] and cemented as the "Observer" pattern in Design Patterns [GHJV95] by the Gang Of Four. In real life, subconsciously plowing along with M, then V, then C often leads to MV with little or no decoupled C. Call this MV/C. With controller code woven deeply into your view, it becomes nearly impossible to later switch out your application's view.
Java applications written using Swing and now being ported to Eclipse are an example of how one can be forced to confront this. If you've got a substantial MV/C application, good luck. With Swing view code mixed with controller logic, porting your application's view to use SWT widgets can almost require a complete rewrite (assuming you don't want to run Swing inside of SWT). If this has happened to you, it should come as no surprise; MVC has been around for some time now...
Previous Topic
