Just reading the iPhone Cocoa developer docs and its description of Model-View-Controller. However, if you look at the diagram rather than the model component directly notifying the view of changes as in classic MVC, in Cocoa the controller acts as mediator, more like the Dialogue component in the Seeheim architecture1 or the Control component in PAC.
The docs describing the Cocoa MVC design pattern in more detail in fact do a detailed comparison with the Smalltalk MVC, but do not refer to Seeheim or PAC, I guess because they are less well known now-a-days. Only a few weeks ago when discussing architecture with my students, I described Seeheim as being more a conceptual architecture and not used in actual implementations now. I will have to update my lectures – Seeheim lives!
- Shocked to find no real web documentation for Seeheim, not even on Wikipedia; looks like CS memory is short. However, it is described in chapter 8 of the HCI book and in the chapter 8 slides[back]
Was thinking MVC came out in 1980 whereas the Seeheim workshop was in 1985.
Is this, more complete Seeheim-MVC, also in the MS OS X 10.6 Cocoa frameworks ?
Yep, I think it is Apple’s take on MVC for all apps desktop and iPhone. However, I wouldn’t say ‘more complete’ Seeheim-MVC as they have different approaches and the Apple MVC is simply more Seeheim-ish rather than more complete. In some ways the ‘classic’ MVC with the direct MV link is rather like the fast switch in Seeheim (maybe influenced it, but don’t know whether MVC people were at Seeheum as it was more UIMS people). Although, when I say ‘classic MVC’ in fact when I looked back to the early MVC work it was quite broad, so would accept a lot of different connectivity paradigms depending on the precise application. Taking a peek at a few Apple examples it looks like the view is in some ways ‘dominant’, whereas when I write MVC it is usually the controller that takes that part.
As a side note I recall a few years ago a student was working with microsoft’s visualisation libraries, which are also MVC-based. That is all the components are MVC *except* the tree view. I think this is probably because the tree view has both the underlying tree and also the pattern of what is open and closed – interaction state. I call this pattern of fundamental state with subsequent layers of interaction state the ‘hydra model’ of interaction architecture (as you chop of a head more appear!). MVC has no placeholder for this interaction state except as part of the controller and in the case of a treeview it is precisely this interaction state that is being updated, so the developers simply didn’t know what was the appropriate model.