MSDN Magazine - June 2008 - (Page 38)

Figure 2 Introducing a Chain of Responsibility public class OrderProcessingModule { private IOrderHandler[] _handlers; public OrderProcessingModule() { _handlers = new IOrderHandler[] { new InternationalOrderHandler(), new SmallDomesticOrderHandler(), new LargeDomesticOrderHandler(), }; } public void Process (OrderStatusMessage orderStatusMessage, Order order) { // Apply the changes to the Order from the OrderStatusMessage updateTheOrder(order); // Find the first IOrderHandler that “knows” how // to process this Order IOrderHandler handler = Array.Find(_handlers, h => h.CanProcess(order)); } handler.ProcessOrder(order); The point of the Single Responsibility Principle isn’t just to write smaller classes and methods. The point is that each class should implement a cohesive set of related functions. An easy way to follow the Single Responsibility Principle is to constantly ask yourself whether every method and operation of a class is directly related to the name of that class. If you find some methods that do not fit with the name of the class, you should consider moving those methods to another class. The Chain of Responsibility Pattern Business rules will probably face more changes throughout the lifecycle of a codebase than any other part of the system. In the OrderProcessingModule class, there was quite a bit of branching logic for order processing based on what type of order was received: if (order.IsInternational) { processInternationalOrder(order); } else if (order.LineItems.Count > 10) { processLargeDomesticOrder(order); } else { processRegularDomesticOrder(order); } } private void updateTheOrder(Order order) { } does its job and I won’t have to go back and change it. You’ll never reach true Open Closed nirvana, but you can inch much closer by rigorously following the related Single Responsibility Principle: a class should have one, and only one, reason to change One of the easiest ways to write classes that never have to change is to write classes that only do one thing. This way, a class only needs to be modified if the exact thing that it does needs to change. Figure 1 shows a sample that does not follow the Single Responsibility Principle. I seriously doubt you’re designing a system like this, but it’s good to remember just why we don’t structure code this way. The OrderProcessingModule is pretty busy. It’s doing data access, grabbing configuration file information, running business rules for order processing (probably very complicated by itself), and transforming completed orders into shipments. Chances are, if you were to build the OrderProcessingModule this way, you would be constantly breaking into this code to make changes. Many changes in system requirements would cause far too many changes to the OrderProcessingModule code, making the system risky and expensive to change. Instead of one big blob of code, you should follow the Single Responsibility Principle to divide the entire OrderProcessingModule class into a subsystem of related classes, with each class fulfilling its own specialized responsibility. For example, you might put all of the data access functions into a new class called OrderDataService and the order business logic in a different class (I’ll go into this in more detail in the next section). In terms of the Open Closed Principle, by dividing the business logic and data access responsibilities into separate classes, you should be able to change either concern independently without affecting the other. A change in physical database deployment might cause you to replace the data access with something completely different (open for extension), while the order logic classes remain completely untouched (closed for modification). 38 msdn magazine It’s very likely that a real order processing system would grow to encompass more types of orders as the business grows—and accumulate plenty of special exception cases such as those for government and favored customers, and special of the week offers. It would be very advantageous for you to be able to write and test new order handling logic without risking breaking one of the existing business rules. To that end, you can move closer to the Open Closed Principle for the order processing example by using a form of the Chain of Responsibility pattern, as demonstrated in Figure 2. The first thing I did was to make every conditional branch in the original OrderProcessingModule into a separate class that implements the IOrderHandler interface: public interface IOrderHandler { void ProcessOrder(Order order); bool CanProcess(Order order); } I would then write a separate implementation of IOrderHandler for each type of Order, including the logic that basically says, “I know what to do with this Order, let me handle it.” Now that the business logic for each type of Order is isolated to a separate handler class, you can change the business rules for one type of Order without worrying about breaking the rules for another type of Order. Better yet, you can add completely new types of order processing with very minimal change to the existing code. For example, let’s say that, at a later time, I have to add support for government orders in the system. With the Chain of Responsibility pattern, I can write a completely new class called GovernmentOrderHandler that implements the IOrderHandler interface. Once I’m satisfied that GovernmentOrderHandler works the way it’s supposed to, I can add the new government order processing rules by a one-line change to the constructor function of OrderProcessingModule: 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.