How did MVC get so F’ed up? Original Smalltalk MVC Definition MVC (Model-View-Controller) as defined in Smalltalk emphasizes three types of objects: Model: The application’s data and logic, unaware of views and controllers except indirectly via notifications. View: Screen presentation of the model. Controller: Defines how the user interface reacts to input. The model is observable and only indirectly linked to the view and controller through observer notifications, which preserves model reusability. Evolution and Misinterpretation Apple’s early definition (circa 2003) distorted MVC by: Letting views edit data. Making controllers intermediaries often non-reusable. Apple has since refined the definition but still implicitly accepts controllers (and view-controllers) as often the least reusable components. In Cocoa, a view-controller bundles many UI elements and models, often creating a large and messy composite object. Key Points of Correct MVC The model is observable; views listen to notifications about changes. Controller and View bind to the model; model does not bind back to them. The view state itself is another observable model (e.g., window visibility, currently viewed tab). MVC is a composite pattern due to the close connection of views and controllers. Observable Model Example Example: An observable boolean model binds to a checkbox UI. Changes propagate from model → view. No querying the checkbox for state; the checkbox solely reflects the model. This is a form of data binding, but with a clear directional flow: model to view. Common Misconceptions and Issues Many UI frameworks incorrectly treat widgets as models themselves, leading to: Ambiguity in what holds the true state. Two-way bindings that don't scale well. Writing observable models can be complex in languages like Pascal or C due to: Object ownership. Lifetime management. Binding expression complexities. Industry compromises, especially those from the Lisa team, introduced inefficiencies and confusion. Complex Models Notifications should specify what exactly changed (e.g., an image removed from a sequence). The model must be “complete”, supporting efficient views of itself. Identification of models in a system is often incomplete; some parts like argument models for functions/commands get overlooked. Argument Models Functions often have arguments built through UI elements. Example: A ‘delete selected images’ button requires a model of the current selection. This argument model signals the ability to enable or disable UI elements (preconditions for commands). Argument models can be shared across commands for consistency. --- References Gamma et al., Design Patterns: Elements of Reusable Object-Oriented Software (1995). Critique of Apple’s old MVC definition (circa 2003). Apple’s current Cocoa MVC documentation. Wikipedia on MVC. Stepanov & McJones, Elements of Programming (2009). Apple’s Key-Value Observing guide. Wikipedia on Object-oriented user interfaces. --- MVC's confusion stems from misunderstanding the role and nature of the model, and the improper blending of controller and view responsibilities, especially in modern UI toolkits. Emphasizing observable models and unidirectional data flow can help restore clarity and improve software design.