MSDN Magazine - June 2008 - (Page 40)

Figure 3 A Simple View-Based App public interface IApplicationShell { void DisplayMainView(object view); } public interface IPresenter { // Just exposes a getter for the inner WinForms UserControl or Form object View { get; } } public class ApplicationController { private IApplicationShell _shell; public ApplicationController(IApplicationShell shell) { _shell = shell; } public void ActivateScreen(IPresenter presenter) { teardownCurrentScreen(); // Setup the new screen _shell.DisplayMainView(presenter.View); } } private void teardownCurrentScreen() { // teardown the existing screen } screens to the application by simply plugging in new Presenters, so the knowledge of these new menu and left pane constructs should go into the existing Presenter abstraction. I’d then have to change the ApplicationShell or the ApplicationController to react to the new menu items and the additional controls placed in the left pane. Figure 4 shows a possible solution. I’ve added new properties to the IPresenter interface to model the new menu items and any additional controls that might be added to the new left pane. I also added some new members to IApplicationShell for these new concepts. Then I added new code to the ApplicationController.ActivateScreen(IPresenter) method. So, did this solution conform to the Open Closed Principle? Figure 4 Trying to Extend IPresenter public class MenuCommand { // } public interface IApplicationShell { void DisplayMainView(object view); // New behavior void AddMenuCommands(MenuCommand[] commands); void DisplayInExplorerPane(object paneView); Not in the slightest. First, I had to modify the IPresenter interface. Since it is an interface, I would have had to find every implementer of the IPresenter interface in my codebase and add empty implementations of these new methods just so that my code could compile again. That’s often an intolerable change, especially if any of these IPresenter implementers are outside your immediate control. More on this later. I also had to modify the ApplicationController class so it knows about all of the new types of customizations each screen might need on the main ApplicationShell. Finally, I needed to modify ApplicationShell to support the new shell customizations. The changes were minor, but then again, it’s not unlikely I’ll want to add even more screen customizations later. In a real application, the ApplicationController class can get complicated enough without having to assume additional responsibilities for configuring ApplicationShell. It would be nice if we could keep this responsibility back in each Presenter. The change to each IPresenter implementation could be alleviated by using an abstract class called Presenter instead of an interface. I could just add default implementations to the abstract class as shown in Figure 5. And I wouldn’t have to change any of the existing Presenter implementations to add the new behavior. There is another way to move closer to the Open Closed Principle ideal that might be cleaner in the end. Instead of putting getters on the IPresenter or BasePresenter abstraction, I could use the double dispatch pattern. I got an unexpected demonstration of the double dispatch pattern in real life the other day. My team had just moved into a new office space and we were battling networking issues. Our networking guru called me last week and started telling me what my coworker should do to connect to the VPN. He rattled off a bunch of networking mumbo jumbo I didn’t understand, so I finally just handed the phone off to my coworker to let them talk directly. public ApplicationController(IApplicationShell shell) { _shell = shell; } public void ActivateScreen(IPresenter presenter) { teardownCurrentScreen(); // Setup the new screen _shell.DisplayMainView(presenter.View); // New code _shell.AddMenuCommands(presenter.Commands); foreach (var explorerView in presenter.ExplorerViews) { _shell.DisplayInExplorerPane(explorerView); } } public interface IPresenter { object View { get; } // New properties MenuCommand[] Commands{ get; } object[] ExplorerViews { get; } } } public class ApplicationController { private IApplicationShell _shell; } private void teardownCurrentScreen() { // teardown the existing screen } 40 msdn magazine Patterns in Practice

Table of Contents Feed for the Digital Edition of MSDN Magazine - June 2008

MSDN Magazine - June 2008 Contents Toolbox CLR Inside Out Cutting Edge Patterns In Practice SAAS Concurrency Robotics Form Filler GUI Library Service Station Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.