Design patterns and dynamic runtime configuration – Visual Studio Magazine
Insider: Design Patterns and Dynamic Runtime Configuration
Peter Vogel helps you understand the benefits of dynamic loading at run time.
On a few occasions I have used Reflection to load classes at runtime rather than adding references to those classes at design time. I won’t say this made it easier to deploy my apps, but I think dynamic loading is a natural departure from object-oriented design principles.
When a class does some of its work by calling a method on another class, the process is called delegation. Creating an application by assembling multiple DLLs is called composition (if the objects involved can survive the application, the technique is called aggregation).
I love composition because it’s a critical part of achieving one of the goals of object-oriented design – to reduce logic in your application. Each additional logical statement (If… Then, Select) increases the complexity of your application, increasing both application debugging / testing time and the chances of something bad creeping into production. These problems, it seems to me, are more difficult to locate than a missing DLL.
Most design patterns, for example, let you replace logic with polymorphic classes: load the right class and everything works. The Strategy pattern, for example, involves passing a “strategy” class to another object which then calls methods on the strategy class. By swapping a different policy class, you can dynamically control what your application does when the methods of the policy class are called. Other than deciding which policy class to pass, no logic is required. The Adapter model allows a class to manipulate any other class by loading an intermediate object: Overriding the adapter class at runtime allows your application to work with any other class. Again, other than choosing the right adapter, no logic is required.
While composition reduces the complexity of your application, it does so at the expense of the complexity of selecting the right parts. Another design pattern comes into play here, as you can often isolate the code that selects and creates the objects in factory classes that only have one task: to create and return the right class. Again, a more manageable problem than dealing with complex logical errors.
Dynamic loading takes it a step further by postponing the decision about which class you will use until the last possible moment: Runtime. With dynamic loading, you configure the functionality of your application by loading the correct class based on the information available when running the application (for example from a configuration file or just evidence lying around in the app. ‘environment).
I used dynamic loading most often for an app I created for a customer that my customer then sold to their customers. My app received data from a number of sources and decided what class it needed to process that data by looking at the incoming data as it arrived. Based on what it found in the data stream, the app looked up a table that specified the assembly and class to use to transform the data into information. If a client needed to process a new input stream, they simply dropped a new DLL into the application folder and added an entry to the table. Indeed, we have created the potential of a third-party market based on this application.
We started this app some time ago, so I built everything with Reflection; if we ever upgrade it, I will rewrite it using the Managed Extensibility Framework (MEF) that comes with Microsoft .NET Framework 4. Whatever tool we use, however, all we need to distribute to developers interested in creating new DLLs for this application is a reference DLL and documentation page.
I just finished working for this client (at least for the foreseeable future). In honor of this event, I’m going to dedicate my next .NET Hands-On Printing column to .NET Framework tools that allow you to implement dynamic runtime composition.
Peter Vogel is a Systems Architect and Director of PH&V Information Services. PH&V provides comprehensive advice, from UX design to object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design are available at http://blog.learningtree.com/tag/ui/.