Ramifications

[Previous] [Next]

• Simplifies complex monolithic conditional constructs If you're developing a system in which new business rules (new behavior) are constantly being introduced based on changes in the state of business objects, a single method implementation that utilizes a Select Case or If…Then…Else construct will soon become unwieldy. Separating state-specific behavior into separate subclasses keeps the code manageable and readable.
• Permits the dynamic addition of new behavior at run time This solution is a perfect fit for systems in which business rules are constantly changing and the time to market is critical. A stock portfolio trading system that automatically trades stocks is an ideal candidate for this type of solution. Imagine changing the trading strategy of an auto-trading system by registering new ConcreteTradeState objects and unregistering existing ConcreteTradeState objects on the fly. This strategy would require the existing code to be recompiled and the system to be restarted to take advantage of the new system enhancements. The State design pattern allows you to avoid this situation. It also provides the benefit of enabling and disabling specific business rules with no recourse. The need to enable and disable specific business rules would be a severe handicap in a single compound conditional construct because it would require further modifications to the conditional checks. For unpredictable changes of events, such as dramatic market swings, an adjustment to the current set of business rules might be required for an immediate correction to a stock portfolio. Such an adjustment would be impossible with the single conditional construction approach.
• Concrete state objects are sharable Concrete state objects all by themselves are stateless. These classes of objects represent state-specific behavior within an applied context that is controlled by a central state manager object. Concrete state objects can be made sharable in any context by incorporating a generic central state manager that can be used with any kind of state object and disabling the use of the application-specific central state manager.
• Concrete state objects are self-reliant class objects The State design pattern allows a client to create an instance of any State subclass. Each subclass implements the behavior required to participate in the State design pattern. Each subclass also represents a unique initial state of an object when the object is first created.
• The State design pattern can increase the number of objects in memory Replacing a monolithic conditional language construct with this design pattern will result in more objects residing in memory. To remedy this situation, objects can be created on demand and released when their reference counts hit zero, or the most frequently used objects can be maintained in a cache.