A recap: we saw that Model-View-Controller started life as Thing-Model-View-Editor, a way of approaching problems to design Smalltalk user interfaces. As Smalltalk-80 drifted off from its ivory tower, many Smalltalkers were using and talking about MVC, although any kind of consensus on its meaning was limited by the lack of important documentation.
Would this telephone game continue to redefine Model-View-Controller as object-oriented programming grew beyond the Smalltalk-80 community?
Part 3: Objective-MVC
Objective-C is now best known as the programming language Apple promotes for developing iOS and Mac applications. It was first available on the Mac during the 1980s pre-Cambrian explosion of OOP languages: on the Mac alone you could send messages using Smalltalk-80, Object Pascal, Objective-C, ExperCommon Lisp, Allegro Common Lisp, Object Assembler, Object Logo, and there were probably more. Most of the list here was derived from Object-Oriented Programming for the Macintosh, written by Kurt J. Schmucker then of Productivity Products International.
Which brings us back to Objective-C, which is probably the best known of the products produced by Productivity Products. Objective-C did not let programmers use a spatial programming interface, it made them use linear text files.
Objective-C also did not follow the Model-View-Controller paradigm of Smalltalk-80. As described by Brad Cox in this figure adapted from Object-Oriented Programming: an Evolutionary Approach, the PPI programmers were thinking about Models and Views, and then about reusing Views in different UIs.
So, what happened to the Controllers? Here’s Cox:
This architecture is very similar to the one used in Smalltalk-80, with one exception. […] The outgoing leg of Smalltalk’s user interface is handled by a hierarchy of views much like the ones discussed here. But the incoming leg is implemented by a separate hierarchy of classes, Controllers, that provide the control for the application. […] The need for the separate controller hierarchy is unclear and is the topic of spirited debate even within the Smalltalk-80 community.
Unfortunately the citation for “spirited debate” is personal communication with various Smalltalkers, so we may never know the content.
This gives us three Objective-C modifications to the original Smalltalk-80 concept that persist to this day. One is the move from a user interface paradigm concerning the interactions of individual objects to a layered architecture. The Cox book shows the display screen as a projection of the view layer onto glass, and the models all in their own two-dimensional layer suspended from the views, hanging:
suspended from the presentation level by pointers in much the way that circuit boards are connected to test equipment with a bed-of-nails testing jig.
That still persists in Cocoa MVC, though with a somewhat weak assertion:
The collection of objects of a certain MVC type in an application is sometimes referred to as a layer—for example, model layer.
The second thing is the abstraction of the Presentation layer away from the display primitives.
The other thing that we still don’t have in ObjC is the Controller. Wait, what? Surely Objective-C applications have Controllers. Apple and NeXT both talked about it, and they have objects with the name “Controller” in them. Surely that’s MVC.
For whatever reason, NeXT kept the ObjC-style Views with their handling of both input and output, but also had to reintroduce the idea of a Controller. So they took the same approach followed by others, notably including Ivar Jacobson a few years later, of defining the Controller layer to contains whatever’s left once you’ve worked out what goes into the Model and View layers.
Now there’s only the question of placement. The Controller can’t go where Smalltalk’s Controllers went, because then it would get in the way of the input events which now need to get to the View. It could go between the two:
A controller object acts as an intermediary between one or more of an application’s view objects and one or more of its model objects. Controller objects are thus a conduit through which view objects learn about changes in model objects and vice versa. Controller objects can also perform setup and coordinating tasks for an application and manage the life cycles of other objects.
Here’s a reproduction of the diagram from that document:
Notice that for the Controllers to act as a mediator between Models and Views, the Views actually have to forward action messages on to the Controllers (via delegation, target-action or the responder chain). Had the Controller been left where it was it would already be receiving those events.
Compare that with the diagram derived from Smalltalk MVC:
It’s clear that these are different concepts that unfortunately share a name.
