I’ve been pondering the subject of my previous post more: creating the ideal language and environment. I realized that the Model-View-Controller paradigm is really quite ideal more than I had ever realized it. But Model-View-Controller isn’t as descriptive as I need to be to express my vision.
Now what’s so special about this? Not too much actually. Model View Controller abstracts Data (Model) from View (interface) and Controller (your program logic). However, the ideal way to implement this I realized needs a little more separation, which I’ve classified as Controllers as well.
In my ideal paradigm, I have these distinctive sets of code:
Controller
The Controller acts as your program’s main logic. This is where the interaction between Model and View resides. This is where most of the initial work of a program usually resides: the prototype has a logically functioning program, and from that initial logic grows a better interface and perhaps better data model.
Model
The Model is your data structure, and minimal data integrity methods or “floodgates.” For example, putting code in the model that ensures a Person has a positive Age is perfectly valid. On the other hand this is not the place to put code to load and save a Person to disk.
This initially sounds counter-intuitive compared to what you would expect in an object-oriented programming world. However, stealing from the ideals of the SOLID principles, the Single Responsibility Principle states that each class and method should only have one responsibility.
People have argued about whether or not this is a good idea. Anecdotally, I’ve seen complicated applications turn core classes into horrible pieces of code. I’ve seen an object start as loading from one source, adding another source, adding more and more logic, and what you end up with is a huge class that is hard to navigate, debug, and understand dependencies.
Instead I like to envision separate controllers to handle IO, which I will come to next.
Model Controller
The Model Controller is the code that takes care of the IO action of the program. For example, you may have a PersonXMLController which knows how to turn a Person into XML. The idea is to create distinct controller which know how to serialize/deserialize your Model into various formats. The Controller (aka your program) would ultimately be in charge of what bits of code to depend upon to function.
This separation has a big benefit of understanding code flow. In the former understanding of data encapsulation, the Person class would maybe start out having a ToXML method. Later we may realize we want to support JSON, so we add a ToJSON method. Turns out that this is all we need, so we stop calling the ToXML method.
This isn’t immediately apparent when looking at the Person class. It has a ToXML method, but it isn’t being used. These sorts of dependencies are at a level that developers don’t usually think about. We like to think about how classes interact, but not really how individual methods are utilized. When we see a class diagram, we’ll see that the Person class is used, but won’t notice that we have an unused method ToXML.
Not only do we not know it’s unused, we have to look at it all the time while looking at our Person class. If the XML logic were held somewhere else, we wouldn’t be looking at it unless we went to it! Additionally, if the XML logic were in its own class, class diagrams become much more useful to look at.
Additionally, I would argue that this doesn’t really prevent data encapsulation. Rather, it promotes the use of a design pattern that is useful when dealing with polymorphic types and IO: the visitor pattern.
View
The View is a representation of what your controller will do at runtime to interact with the user. For a desktop application, this may mean a window. For a web application, it may mean an Ajax-based website. For a mobile phone, it may mean a table view. For a console application, it may mean a set of input/wait scenarios with printing the result of a computation.
The idea of the View is not to actually create the user interface, but to abstract the user interface to a specific task. For example, I wouldn’t want to describe the interface at this level as being a blue, pulsating push button with width of 80 pixels and height of 20 pixels located at 14 pixels from the right, and 20 pixels from the bottom of the window. Instead, I would describe that I want a button that is the default button that is connected to a specific action.
The grunt work of actually taking this representation and turning it into actual controls with proper metrics is the work of the view controller.
View Controller
The View Controller takes a View and turns it into the most appropriate interface for the platform the application is running under. The idea behind a view controller is that this is the area that the platform specific details are sorted out: metrics to follow the platform’s UI guidelines and specific controls and colors that match the user’s theme.
The only reason to abstract the View Controller from the View is when you’re targeting multiple platforms. For example, a pushbutton on Mac OS X has a height of 20 pixels, while on Linux it is based on the theme and font.
Putting it all together
At first glance, all of the above seems like additional work over what we call the MVC architecture today, and I will admit that if you hand-code each of these elements, it is more work.
However, my vision is for the ideal language and platform, and upon contemplating what parts of programming aren’t fun, I focused on two major aspects: IO and pixel pushing.
Ideally what I’ve described as View Controllers and Model Controllers would be pre-coded and ready to use. Need your object in JSON? Just use the JSONController. Need you object in XML? Just use the XML controller? Need it in a SQL Database? Just use the SQLController. Need to customize something about that output? Put some annotations on the model or implement some events off the model controller.
Want to tweak the interface? Implement some events off of the view controller.
The idea is that writing a program shouldn’t be about agonizing over the little bits of how to store the data or how to make your window look right on both Windows and Mac OS X. It should be about solving the problem that your program is out to solve. After all, that’s where the most fun remains.
1 year ago
