In StoryArchitect, we make use of the view hierarchy itself to pass down a shared SelectionContext and to bubble events up from the deepest subcomponents. Thus we do not really need much mediation. We are going to use some pop ups to get things done as well, but we will talk about how we handle them in Chapter 9.

So far, we are sure that we need these three Mediator subclasses:

In our case, there is no common functionality we need to share between these Mediator subclasses, so there is no need to create an AbstractMediator as we did with AbstractProxy. All these classes will extend Mediator and override or add the methods necessary to communicate with their View Components and the rest of the system. In the following implementations, note how every View Component does not necessarily dispatch (or bubble through) events that the Mediator needs to handle. Similarly, some Mediators have no Notification interests. The balance of Event and Notification handling responsibilities is different for every Mediator/View Component pair, but usually includes some of both. It just so happens that these particular Mediators ended up doing one or the other.