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

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
xperience suggests the working life of applications is enhanced if developers acknowledge the inherent requirements of standards-based development. For instance, if an application is based on emerging or evolving technology, then it must be able to easily adapt to changes in the standards related to that technology. If it is based on technology for which there are competing standards, then it should be configurable and capable of supporting any of the available standards.

The trouble is, developers too often find that these requirements result in complicated, hard-coded, conditional logic strewn throughout their application code. This code can get downright ugly when some of the conditions require common processing. As support for standards changes, the conditional logic can become increasingly difficult to read and extremely fragile, and even the most conscientious developer could inadvertently introduce a subtle error based on a misunderstanding of the code.

What You Need
Some familiarity with object-oriented programming, design patterns, and Java.

However, support for myriad standards, or conditional behaviors in general, can be achieved without sacrificing flexibility, robustness, or maintainability. Ideally, conditional behaviors should be isolated, and should not require changes to the main application code. By applying two well-known software design patterns, you can encapsulate the conditional behavior in one or more classes to make your code more readable, easier to maintain, and less susceptible to errors. Using this particular combination of design patterns will also allow your applications' behaviors to be configurable.



The Crucial Role of Design Patterns
The two design patterns that are key to writing highly-maintainable applications that are also malleable to standards evolution are Strategy (a.k.a. Policy) and Abstract Factory.

The intent of the Strategy pattern, as defined by Erich Gamma et al in their book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley), is to "Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it." If you replace the word "algorithms" in this definition with "conditional behaviors," the result is a description of our goal. Therefore, the Strategy pattern is obviously applicable to the problem.

The Abstract Factory pattern is applied to achieve a loose coupling between the application and the configurable conditional behaviors so they can vary independently.

Suppose you're developing an application that routes SOAP messages. Criteria for making routing decisions are innumerable. It follows that your application design must not, as much as possible, preclude the use of these criteria. Some standards that specify a set of criteria illustrate this assertion. For instance, the application ideally supports current Web services routing standards such as WS-Routing, WS-Referral, and WS-Addressing. Moreover, your application should also support emerging standards, or modifications to the existing standards. Additionally, it should be easy to develop proprietary or custom routing algorithms independently from the router application itself.

A typical solution developers might use for this routing example is shown in Listing 1. Perhaps this class was initially developed with a single algorithm in mind, before any of the Web services standards were defined. Since then, support for some of the standards was added, and additional algorithms were requested by customers. The current implementation, see Listing 1, only supports two algorithms, with a place-holder for a third; the route method is already quite long.

The Real Challenges of Application Development in Changing Times
Some developers might ask, "So what if the route method is long?" As Martin Fowler suggests in Refactoring: Improving the Design of Existing Code (Addison-Wesley), longer procedures are difficult to understand. There are other techniques for reducing method length, but the length of the route method is not the only problem. Consider some others:

  • Depending on complexity, conditional logic can detract from readability.
  • There is a high likelihood of duplicate code among similar algorithms. Be aware: the typical solution to this problem, unifying code, can add even more complex conditional logic while trying to isolate the similarities.
  • The addition, removal, or modification of an algorithm requires that the router application, or at least the SOAPRouter class, be modified and recompiled.
  • Removing an algorithm can easily result in lingering unused data structures or methods because its implementation is not encapsulated.

Adding a New Algorithm
Let's consider the steps required to add a round robin algorithm to the application. First, there has to be a unique identifier for this algorithm. Begin by checking all existing identifiers to choose one that is not already used. Second, add a data member to keep track of the round robin state. Next, add the algorithm implementation to the route method. Finally, recompile the SOAPRouter class. Listing 2 shows the updated class.

While adding an algorithm complicates the SOAPRouter class, removing or modifying an algorithm can cause more confusion because it's easy to remove or change the "else if" block from the route method, and inadvertently leave lingering data structures and algorithm identifiers. These lingerers make the class confusing and difficult to read. If left unresolved, over time, the responsibilities and capabilities of the SOAPRouter class become unclear.



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