Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Make Applications Stand the Test of Time : Page 2

Applications built on industry standards increasingly favor enterprise environments that can't be locked to a single vendor solution. Apply well-known software design patterns to build applications that support configurable dynamic behavior.


advertisement
Leveraging Design Patterns
With a clear understanding of these development challenges, let's apply appropriate design patterns to address them. The result is illustrated by the class diagram in Figure 1.

Figure 1. Refactored SOAP Router Architecture: The new architecture is the result of applying the Strategy and Abstract Factory design patterns.
The algorithm implementation code is encapsulated in individual classes, each of which implements the RoutingStrategy interface. A RoutingStrategy implementation in this architecture is an algorithm definition. SOAPRouter now uses a RoutingStrategy instance to route request SOAP messages. It neither knows nor cares about how the SOAP messages are routed. The refactored SOAPRouter code is shown in Listing 3.

Listing 4 shows the WS-Routing RoutingStrategy implementation, and Listing 5 shows the round robin implementation.



Now, the process of adding the round robin algorithm is reduced to a single step. Simply set the value of the RoutingStrategy system property (the name of the property is determined by the RoutingStrategyFactory implementation) to routing.strategy.RoundRobinRoutingStrategy. There is no need to recompile SOAPRouter because no changes were required. Removing the algorithm is just as easy; just set the system property to another value.

Clearly Measurable Benefits for Developers
Conditional logic and associated problems are eliminated using the above technique, making the code more readable. Duplication of code can be limited through inheritance; Families of algorithms can be developed as a hierarchy with common code in one or more base classes. The refactored router code is concise, and the responsibility of the SOAPRouter class is clear.

Because the SOAPRouter class now uses the RoutingStrategyFactory to create RoutingStrategy instances, rather than constructing concrete implementations, it can vary independently from the algorithms. As such, algorithms can be implemented and modified without requiring the router source code to be recompiled. Adding or removing an algorithm from the router is a configuration step, and enables customers to implement their own routing algorithms without requiring access to the application source.

Also significant, there is no need to define unique identifiers for each algorithm; an algorithm's implementation class name essentially serves as its unique identifier. Nor is there a possibility of clutter or lingering data structures because each algorithm is encapsulated in its own class. Removing an algorithm has become a one-step process.

The configurability is provided by virtue of the RoutingStrategyFactory implementation. The example implementation relies on a system property to determine which RoutingStrategy implementation to use and reflection to create instances of the configured type. To configure an algorithm, a developer needs only to specify the desired implementation class name as a system property. One benefit of this implementation is that the algorithm can be changed at runtime (assuming there is a means for setting this system property while the application is running).

This article focused on one application of a technique for solving a general problem. Hopefully, you can see its universal value in building dynamic applications with configurable behavior. Maybe, next time you encounter a class with a lot of confusing conditional logic, you'll refactor it using this technique. Anyone who has to maintain that code after you will surely thank you for you effort.



Phil Zampino is a Senior Software Engineer for Hewlett-Packard's OpenView Division. He has over 5 years of professional experience developing object-oriented software, and is currently involved in projects developing web services management technology for OpenView. Reach him by e-mail .
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date