Presentation Patterns – Supervising Presenter

Like the Autonomous View, this is another one of Martin Fowler’s patterns. He calls it Supervising Controller, but suggests the alternative name of Supervising Presenter. I’m voting for the latter for the following reasons:

  • This pattern is a derivative of the Model-View-Presenter pattern rather than Model-View-Controller, so ‘Supervising Presenter’ seems a more suitable name.
  • Due to excessive overloading, the meaning of the term ‘controller’ in UI architecture discussions has become somewhat vague.
  • The ‘Presenter’ object is neither a controller in the J2EE / Model-2 / Cairngorm sense of the word, nor does it have much in common with the controllers from the original Smalltalk-MVC architecture.

Key features

  • State is in the view
  • Logic is in the Presenter
  • Presenter observes the view
  • Presenter updates the view
  • Presenter ‘knows’ about the view
  • View does not ‘know’ about the Presenter

Unlike the Autonomous View, the Supervising Presenter aims to extract non-trivial presentation logic out of the view into a separate class known as a Presenter. The view retains some autonomy, and controls in the view can still bind directly to underlying domain or value objects.

One very important feature of the Supervising Presenter pattern is that the view is unaware of its associated Presenter, but the Presenter is aware of the view. This is a trait inherited from Model-View-Presenter and is a principal difference between MVP and MVC. Each Supervising Presenter must observe its associated view for user events and coordinate the necessary view / model updates in response.


Two reasons for adopting the Supervising Presenter pattern would be to address the drawbacks of the Autonomous View pattern:

Easier to test

Separating complex presentation logic into a separate class should facilitate unit testing. But there is one big fly in the ointment: The Supervising Presenter has a dependency on the associated view. So to test a Supervising Presenter you either need instances of your actual views, or ‘mock’ objects that simulate the behaviour of the views. If you use your actual view components, you’ll probably experience the same unit testing problems as you would with an Autonomous View

Improved separation of concerns

Following the Supervising Presenter pattern should yield an application-specific class hierarchy that is separated from the view classes, but coupled to them. Common presentation concerns can be refactored into Presenter base classes, and this should help to reduce code-duplication and improve consistency across an application.


How much logic do we extract?

The question of how much ‘supervision’ a view needs is difficult to answer. The Supervising Presenter pattern exists half-way between Autonomous View (which we have already seen) and a pattern known as Passive View. The Passive View pattern extracts all logic from the view into a Presenter class, including bindings. For my own example, I have extracted any logic that cannot be expressed by a simple binding statement. I have also left the validators in the view, as they can be configured declaratively. But the lack of clarity on how much logic to extract may lead to inconsistencies on larger development projects.

Mock objects? What mock objects?

The use of mock objects is a common strategy when unit testing, but creating mock objects to simulate Flex views may not be a trivial task. Then again, once it is done the resulting mock-object library could be reused on other projects.

Logic is extracted but ‘state’ remains in the view

The Supervising Presenter pattern extracts presentation logic from the view, but leaves presentation state in the view. A purist may argue that this is only a partial refactoring: In an OO architecture, state and associated logic are usually encapsulated within the same class. Dogma perhaps, but in my experience strong encapsulation does facilitate refactoring and reuse.

Example application

The example application demonstrates my take on the Supervising Presenter pattern. As with the Autonomous View demo, there’s additional information accessible via the View Source option.

Final thoughts

Despite the issues described above, I do think the Supervising Presenter deserves more attention. It holds the promise of improved unit test coverage, and may help to decrease code-duplication in an application. So far I haven’t encountered a Flex application that uses the Supervising Presenter pattern, so I guess my example must be the first. Perhaps you know different.

Up next: Presentation Model