MSDN Magazine - August 2008 - (Page 43)

public void SubmitTrade(Trade trade) { // pre-processing PricingSystem pricingSystem = new PricingSystem(); pricingSystem.Price(trade); } // persist the Trade and send the proper notifications Figure 5 Decoupling Responsibilities // Information Holder class that maps the IP address of the // physical scanner to the logical "Position" within // the factory public interface IFactorySensorMap { Position FindPositionFromScannerAddress(IPAddress address); } // The business processing code public interface IShippingSystem { void BoxDetectedAt(string barCode, Position position); } // The Coordinator class that listens for socket requests public class ScannerListener { private IFactorySensorMap _sensorMap; private IShippingSystem _shippingSystem; // scanDetected is called as the result of detecting an // incoming Socket call private void scanDetected(string barCode, System.Net.IPAddress ipAddress) { Position position = _sensorMap.FindPositionFromScannerAddress(ipAddress); _shippingSystem.BoxDetectedAt(barCode, position); } } The value of the Facade is that the pricing functionality is easy to consume because there is just a single class and method to call without forcing the consumer of the subsystem to be an unmanageable monolithic block of code. If every dependency on pricing in the system goes through PricingSystem, you have much more freedom to change the pricing subsystem without having to worry about breaking or changing other parts of the system. A coordinator reacts to events and relays commands to other objects. A coordinator is valuable when you have a process that is event driven and it is convenient to decouple listening or detecting events from the processing that occurs when an event is triggered. As an example, I worked on a shipping system that automated the flow of boxes and activities on a factory floor. The system would direct other actions and process data when it received socket messages from physical scanners along the floor. Let’s break that problem down into the responsibilities: 1. One way or another, you need to listen for socket messages from the physical scanners. 2. You need to route boxes throughout the system once a box reaches a certain point on the factory floor. 3. It may not be obvious, but you must translate between the IP address of the incoming socket communication and the physical or logical location of the scanner on the factory floor. The real system from this example combined all three responsibilities in the same class—to everyone’s sorrow. The business processing couldn’t be tested without having the scanners replicated in a testing lab. You’ve got to test everything together at some point, but it would have been much more efficient to have the business processing tested in isolation before bothering with the integration testing. Reading the code was a nightmare because we had to translate IP addresses in the code into their logical meaning. The main reason not to write code this way is that all three responsibilities identified above change independently of each other. I shouldn’t have to touch business logic code when the factory changes to a different type of physical scanner or has to change the IP address when a scanner is replaced. Instead, I’ll separate the responsibilities into three classes as shown in Figure 5. The advantage of this design is that I’ve completely decoupled the shipment routing functionality from the physical infrastructure of the factory floor. This design would have given the shipping system team far greater abilities to simulate factory scenarios and enabled them to push automated testing out of the specialized testing lab. A multithreaded business process is another great example of the value of a coordinator. Getting thread management code right msdnmagazine.com Coordinator } is hard enough without having to wade through intermingled business logic. From experience, business logic is much harder to understand when it’s embedded directly inside of thread management code. In this case, you can make both responsibilities easier to code, understand, and test by using a coordinator class to manage the threads and simply tell a separate business processing object when events occur. The business logic can then be written and tested independently of the thread management code. Controller A controller object directs the actions of other classes. A controller is differentiated from a coordinator by the level of control. A controller doesn’t just tell other objects that an event happened; the controller decides what the other objects should do based on runtime conditions. Going back to the energy trading system example, let’s say you need to create a screen in a user interface to purchase a quantity of gasoline. Before the new purchase trade can be entered into the system, the screen needs to check whether there is enough gasoline in inventory. If there is enough inventory to fulfill the requested quantity, the system will decrement the on-hand inventory by the requested quantity and submit the new trade. If there is not enough inventory, the screen should show a message box indicating that the requested trade cannot be made. Using object role stereotypes, you would first define the responsibilities of this screen as something like this: 1. You need an interfacer to capture the user input and show warning messages. 2. You have to process a new trade, so you could build a service provider to process that trade. 3. You need to fetch and update the on-hand inventory, so create another service provider to access and update the on-hand inventory. 4. You have to compare and also subtract two quantities of gasAugust 2008 43 http://msdnmagazine.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.