MSDN Magazine - June 2008 - (Page 42)

Figure 7 BusinessProcess that Cannot Abstract IDataSource public class BusinessProcess { private IDataSource _source; public BusinessProcess(IDataSource source) { _source = source; } public void Process() { long theKey = 112; // Special code if we’re using a FileSource if (_source is FileSource) { ((FileSource)_source).LoadFile(); } try { Entity entity = _source.FindEntity(theKey); } catch (System.Data.DataException) { // Special exception handling for the DatabaseSource, // This is an example of “Downcasting” ((DatabaseSource)_source).CleanUpTheConnection(); } } } Figure 8 Better BusinessProcess public class BusinessProcess { private readonly IDataSource _source; public BusinessProcess(IDataSource source) { _source = source; } public void Process(Message message) { // the first part of the Process() method // There is NO code specific to any implementation of // IDataSource here Entity entity = _source.FindEntity(message.Key); } // the last part of the Process() method out making any change to the BusinessProcess class. You might start out with a simple XML file-based mechanism, and then move to using a database for storage, followed eventually by some sort of caching—but you still don’t want to change BusinessProcess class. All of that is possible, but only if you follow a related principle: the Liskov Substitution Principle. Roughly stated, you are following the Liskov Substitution Principle if you can use any implementation of an abstraction in any place that accepts that abstraction. The BusinessProcess should be able to use any implementation of IDataSource without modification. BusinessProcess should not know anything about the internals of IDataSource other than what is communicated through the public interface. To put it into perspective, Figure 7 shows an example that flunks the Liskov Substitution Principle. This version of the BusinessProcess class has specific logic to bootstrap a FileSource and also relies on knowledge of some specific error handling logic for the DatabaseSource class. You create the implementers of IDataSource such that they can handle all of their specific infrastructure needs. Doing this will enable the BusinessProcess class to be written, as shown in Figure 8. Finding Closure } Liskov Substitution Principle As I said earlier, the most common manifestation of the Open Closed Principle is using polymorphism to substitute an existing part of the application with a brand new class. Let’s say that at the beginning of the day you have a class called BusinessProcess whose job is to, well, execute a business process. Along the way, it needs to access data from a data source: public class BusinessProcess { private IDataSource _source; public BusinessProcess(IDataSource source) { _source = source; } Just remember, the Open Closed Principle is only realized by polymorphism if a class only depends on the public contract of the other classes it interacts with. If a class that uses an abstraction has to downcast to a specific subclass in one section, you’re not following the Open Closed Principle. If a class that uses another class embeds knowledge about the internal workings of its dependency (like assuming that results of a method are always sorted from big to small), then you can’t actually substitute another implementation for that dependency. Those types of implicit coupling to a specific implementation are particularly pernicious because they aren’t obvious to a reader of your code. Don’t let the consumer of an abstraction depend on anything but the public contract of that abstraction. I would recommend that you treat the Open Closed Principle as a design vector rather than an outright goal. If you try to make everything that you think could possibly change fully pluggable, you’re likely going to create an over-designed system that is very difficult to work with. You may not always manage to write code that satisfies the Open Closed Principle in every aspect, but even moving partway there can be beneficial.  } public interface IDataSource { Entity FindEntity(long key); } Jeremy miller A Microsoft MVP for C#, Jeremy is the author of the open source The design follows the Open Closed Principle if you can extend the system by swapping out implementations of IDataSource with- 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. 42 msdn magazine Patterns in Practice http://structuremap.sourceforge.net http://storyteller.tigris.org http://codebetter.com/blogs/jeremy.miller http://codebetter.com/blogs/jeremy.miller

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.