MSDN Magazine - August 2008 - (Page 44)

Figure 6 EnergyTradingController public class EnergyTradingController { private readonly EnergyTradingScreen _screen; private readonly InventoryRepository _repository; private readonly TradeService _service; public EnergyTradingController( EnergyTradingScreen screen, InventoryRepository repository, TradeService service) { _screen = screen; _repository = repository; _service = service; { createTrade(requestedQuantity, customer); } else { // Cannot fulfill the trade, so tell the screen to show a user // message _screen.DisplayQuantityUnavailableMessage(requestedQuantity); } } private void createTrade(Quantity requestedQuantity, Customer customer) Trade newTrade = _service.StartTrade(customer, requestedQuantity); // Decrement the onhand inventory so we don't over allocate _repository.ReserveQuantity(newTrade); // Now we can go ahead and make the trade _service.SubmitTrade(customer, requestedQuantity); } public void Purchase(Customer customer, Quantity requestedQuantity) { // First, we need to decide if the trade could be fulfilled Quantity onhandQuantity = _repository.GetOnHandQuantity(); if (requestedQuantity.IsLessThan(onhandQuantity)) { // There is enough inventory to fulfill this request, so place // the new trade } } oline, which may not be expressed in the same units of measure (the inventory may be stored in metric tons and the requested quantity might be expressed in barrels). The Quantity class discussed earlier can handle this responsibility. 5. Some class needs to be the controller for the screen and proceed to govern the workflow of the requested trade. Once you see these responsibilities, you might start creating three new classes. The first class is an EnergyTradingScreen that is the actual view to display the warning messages and capture the user data entry. This could be done with either Windows® Presentation Foundation (WPF) or a Windows Forms control. The second class is an InventoryRepository service provider to fetch and update inventory data. The third class is a TradeService service provider to submit a new trade into the system. This solves some of the tasks in the system, but there is still something missing. You still need to assign the controller responsibilities to some class. Let’s examine the existing candidates. The TradeService and InventoryRepository classes are a poor fit. The workflow responsibility doesn’t fit in with the responsibilities of a service provider class. The most common design would be to make the EnergyTradingScreen responsible for the workflow, but that has some negative consequences. Instead, you should create a whole new class. Using the Supervising Controller pattern (a form of Model View Presenter), you can put the workflow in a new controller class called EnergyTradingController, shown in Figure 6. There are a lot of advantages to extracting a separate controller class. The workflow is easy to understand by just scanning EnergyTradingController because the workflow is the only thing happening in this class. The details of how user messages are displayed, how inventory is really stored in the system, or how trades are processed within the system are managed by other classes. More importantly, pulling the workflow out of the other classes 44 msdn magazine Designing software is an exercise in managing complexity. eliminate the complexity of any given class by assigning it a discrete set of responsibilities. allows those other classes to be simpler and more focused on providing a single service. When I remove workflow responsibilities from the service provider classes, I greatly improve my ability to reuse these services in other contexts besides this one energy trade screen. Designing software is often an exercise in managing complexity. While the overall solution is necessarily as complex as the problem that you’re trying to solve, you can take steps to limit the complexity of any given class by only assigning it a discrete set of responsibilities. When you’re deciding where a new responsibility should go, you should ask yourself what object role stereotype fits the new responsibility and look for suitable classes that match that stereotype. It’s not just a matter of the initial creation of the code. Your objects will change over time as bugs are fixed and new functionality is added to existing code. It’s often the later releases where the design of a system goes irretrievably wrong as the initially clean structure is corrupted and obscured by layers of cruft. Understanding the object role stereotypes of existing classes can help you know where to assign new responsibilities and give you additional clues for when a completely new class should be added to the system.  Using Object Role Stereotypes Effectively Jeremy miller is a Microsoft MVP for C#. He is the author of the open source StructureMap (structuremap.sourceforge.net) tool for Dependency Injection with .NET and the forthcoming StoryTeller (storyteller.tigris.org) tool for supercharged FIT testing in .NET. Visit his blog, “The Shade Tree Developer,” at codebetter.com/ blogs/jeremy.miller, part of the CodeBetter site. Patterns in Practice http://structuremap.sourceforge.net http://storyteller.tigris.org http://codebetter.com/

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

MSDN Magazine - August 2008 Toolbox CLR Inside Out Basic Instincts Cutting Edge Patterns in Practice Data 2.0 - Expose And Consume Data In A Web Services World Biztalk EDI - Build A Robust EDI Solution With BizTalk Server Silverlight - Create Animations With XAML And Expression Blend Write On! - Create Web Apps You Can Draw On With Silverlight 2 Wicked Code - Craft Custom Controls For Silverlight 2 Team System Foundations Windows With C++ Concurrent Affairs Going Places { End Bracket }

MSDN Magazine - August 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.