macOS MVC - Multiple Controllers?

[nutthick]

I'm in the planning process for a new, non-Document-based, App. I would like the system to be architected around an MVC model, but I can't help thinking that the controller is going to become overly complex, once I start adding details of all the controls for the multitude of windows that will be required.

For an MVC architecture, do you only have a single Controller for the whole app, or do you use multiple controllers for different functional areas, i.e. preferences panel, main window?

Thanks

 

[JVene]

Your question suggests you're at that point where you need to read a good text on design patterns, and I can hardly recommend a better starting point than the 'Gang of Four' book, "Design Patterns - Elements of Reusable Object-Oriented Software". They discuss MVC and most of the important patterns, which answer your question in detail.

It is not 'required' or even 'typical' to insist on a single controller class. Within AppKit, you'll find there are controllers reflecting several of the classes implementing controls (buttons, text fields, sliders, etc), each one specialized for a particular job. For that matter, there isn't usually a single view class, either, nor is there always a single model class. If you had a collection of objects, for example, that were to be displayed alternately as a pie chart, a text chart and a bar chart, you might have 3 view objects, one for each format. Similarly, you might have a control object associated with each of these views specializing in control responses specific to each of the view formats uniquely.

The "Gang of Four" book, however, takes you way beyond MVC, into recognizing variations of design patterns that apply to a range of typical, recognized design issues that repeatedly appear in the history of ambitious software development projects, which apply generically to a great many applications in one way or another. The book covers how 8 patterns were used in the design of a text/graphic editor application called Lexi. Design patterns are described in a language independent fashion, drawing upon sample implementations in Java, C++ and other languages. One pattern they don't discuss is RAII, which may have been considered to specific to C++, since several popular languages can't easily support the pattern.

 

[nutthick]

Thanks JVene, I'll take a look.

 

[lazydog]

Just my 2 cents worth - for views that share the same model, you could have separate controllers but a controller will need a way of informing the other controllers that the associated model has changed. You could either hard wire these connections, or implement the observer/listener pattern which is described in the book JVene mentioned. For example, the model would maintain a list of observers, and on start up/initialisation, each controller would register as an observer of the model. Now, when a model is changed by a controller, the model would inform all the other registered observers that it has changed in some way. The controllers observing the model would then know that they have to update their views accordingly.

b e n