MSDN Magazine - June 2008 - (Page 37)

Jeremy miller Patterns in Practice The Open Closed Principle This is the first installment of a new MSDN® Magazine column on software design fundamentals. My marching orders are to discuss design patterns and principles in a manner that isn’t bound to a specific tool or lifecycle methodology. In other words, my plan is to talk about the bedrock knowledge that can lead you to better designs in any technology or project. I’d like to start with a discussion of the Open Closed Principle and other related ideas popularized by Robert C. Martin in his book, Agile Software Development, Principles, Patterns, and Practices. Don’t be turned off by the word “agile” in the title, because this is all about striving for good software designs. Ask yourself this: how many times do you start writing a brand new application from nothing versus the number of times you start by adding new functionality to an existing codebase? Chances are good that you spend far more time adding new features to an existing codebase. Then ask yourself another question: is it easier to write all new code or to make changes to existing code? It’s usually far easier for me to write all new methods and classes than it is to break into old code and find the sections I need to change. Modifying old code adds the risk of breaking existing functionality. With new code you generally only have to test the new functionality. When you modify old code you have to both test your changes and then perform a set of regression tests to make sure you didn’t break any of the existing code. So you generally work on an existing codebase, but yet it’s easier to write all new code than it is to change old code. Wouldn’t you like extending an existing codebase to be as productive and frustration-free as writing all new code? This is where the Open Closed Principle comes into play. To paraphrase, the Open Closed Principle is stated as: software entities should be open for extension but closed for modification. It sounds like a contradiction in terms, but it’s not. All it means is that you should structure an application so that you can add new functionality with minimal modification to existing code. I used to think that the Open Closed Principle just meant using plug-ins, but there’s more to the story than that. What you want to avoid is to have one simple change ripple through the various classes of your application. That makes the system fragile, prone to regression problems, and expensive to extend. To isolate the changes, you want to write classes and methods in such a way that they never need to change once they are written. Figure 1 This Class Does Too Much public class OrderProcessingModule { public void Process(OrderStatusMessage orderStatusMessage) { // Get the connection string from configuration string connectionString = ConfigurationManager.ConnectionStrings[“Main”] .ConnectionString; Order order = null; using (SqlConnection connection = new SqlConnection(connectionString)) { // go get some data from the database order = fetchData(orderStatusMessage, connection); } // Apply the changes to the Order from the OrderStatusMessage updateTheOrder(order); // International orders have a unique set of business rules if (order.IsInternational) { processInternationalOrder(order); } // We need to treat larger orders in a special manner else if (order.LineItems.Count > 10) { processLargeDomesticOrder(order); } // Smaller domestic orders else { processRegularDomesticOrder(order); } // Ship the order if it’s ready if (order.IsReadyToShip()) { ShippingGateway gateway = new ShippingGateway(); // Transform the Order object into a Shipment ShipmentMessage message = createShipmentMessageForOrder(order); gateway.SendShipment(message); } } So how do you go about structuring code to isolate changes? I’d say that the very first step is to follow the Single Responsibility Principle. Single Responsibility Principle In following the Open Closed Principle, I want to be able to write a class or a method and then turn my back on it, comfortable that it Send your questions and comments to mmpatt@microsoft.com. June 2008 37

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.