The next stop on our voyage through the Design Patterns galaxy takes us to the Lazy Initialization technique, the second of two design patterns we’ll encounter that is not registered in the GoF catalog. We will find this design pattern useful in optimizing components.
Initializing components used during the execution of programs is a common housekeeping task applicable to both procedural and object-oriented programming. We may find that initializing these components at the beginning of execution incurs performance and storage consumption penalties when later we determine that some initialized components are never used.
Let There Be Light
Imagine you have completed your work day and have finally arrived home after sunset. Upon entering your home through the front door, you reach over to the light switch and click it into the “on” position. Most likely this will illuminate a light or two near the front door. It would be unlikely that your home is configured such that every light in your home is controlled by this single light switch by the front door. Although such an arrangement might save you the trouble of clicking other light switches as you move through your home, chances are you will not have a reason to move into every room in your home. Even if you did visit every room, it would probably be unnecessary for all rooms in your home to be illuminated at the same time, which would constitute a colossal waste of energy in addition to the high electric bills.
Instead, most homes are configured such that each room has its own light switch to control the light in the room. We can turn the light on as we enter a room and off as we leave, making much more efficient use of energy. In short, we do not consume the energy it takes to light a room unless we actually are using the room.
The same concept is applicable to programming: do not initialize a component until the component will be used. Unlike lights in homes, where the cost to operate the light is fairly constant, the cost to initialize program components is dependent on the component itself, and some are expensive to make available for use.
Delay Tactics
Lazy initialization is not categorized by GoF. Indeed, it is not so much a design pattern as it is a programming technique. The intent behind it is the following:
Delay the creation of an object or performance of an expensive operation until the moment it is needed.
Used judiciously, this technique has the potential to improve performance dramatically and to avoid the excessive consumption of storage.
Lazy initialization is the antithesis of what is known as eager initialization , a technique by which a component is initialized early in the execution of a program under the expectation that the component will always need to be available at some time during processing.
An example of using lazy initialization is the way in which we might create the various aircraft states explored in the previous chapter. The eager initialization technique is when you create three state objects (atGate, onTarmac, and flying) for each aircraft. The assumption is that each aircraft for which we have created these states is expected to transition to each of these states at some time during its operation.
Suppose we were to board a flight on one of these aircraft while it is in the atGate state. The doors close after everyone has boarded and the aircraft pushes away from the gate, transitioning to the onTarmac state. At this point the aircraft has transitioned between two of its three possible states. As we settle in while the pilot taxis the aircraft toward the runway, we hear the dreaded announcement coming over the intercom:
“This is your captain speaking. We are experiencing mechanical difficulties and will be returning to the gate.”
Moments later the aircraft transitions from the onTarmac state to the atGate state, at which point all passengers disembark, followed again by the aircraft transitioning to the onTarmac state as it is towed to the hangar for repairs. It never gets a chance to transition to the flying state. Accordingly, the flying state object never gets used by this hapless aircraft object.
With lazy initialization, each of the state objects is instantiated at the moment it becomes known that there will be a transition to the corresponding state. An onTarmac state instance is created only upon pushing away from the gate. Accordingly, there would be no flying state object created for an aircraft forced to return to the gate due to mechanical difficulties.
Lazy Initialization in ABAP
Here is how we might implement the lazy initialization technique into the code for the UML diagram described in Figure 22-6 of the previous chapter, where the classes at_gate_state, on_tarmac_state, and flying_state all inherit from the state class, and where an airplane class is composed with references to state objects.
Listing 23-1 shows the definition of the airplane class from Listing 22-5. Its three public “switch” methods are intended to update the current_state attribute with a reference to the applicable state class.
Listing 23-1. Class airplane
class airplane definition.public section.methods : constructor, requestimporting action type string, switch_to_at_gate_state, switch_to_on_tarmac_state, switch_to_flying_state.private section.data : current_state type ref to state, at_gate_state type ref to state, on_tarmac_state type ref to state, flying state type ref to state.endclass.class airplane implementation.method constructor.create object at_gate_statetype at_gate_stateexporting aircraft = me.create object on_tarmac_statetype on_tarmac_stateexporting aircraft = me.create object flying_statetype flying_stateexporting aircraft = me.call method me->switch_to_at_gate_state.endmethod.method switch_to_at_gate_state.me->current_state = me->at_gate_state.endmethod.method switch_to_on_tarmac_state.me->current_state = me->on_tarmac_state.endmethod.method switch_to_flying_state.me->current_state = me->flying_state.endmethod.ooendclass.
Notice that the constructor for the airplane immediately creates instances to state classes for all of the states through which it could transition during processing. This may mean that instances of state objects are being created that will never be used during processing. Listing 23-2 shows how the airplane class of Listing 23-1 is changed to use the lazy initialization technique, with differences highlighted.
Listing 23-2. Class airplane with Differences from Listing 23-1 Highlighted
class airplane definition.ooendclass.class airplane implementation.method constructor.create object at_gate_statetype at_gate_stateexporting aircraft = me.create object on_tarmac_statetype on_tarmac_stateexporting aircraft = me.create object flying_statetype flying_stateexporting aircraft = me.call method me->switch_to_at_gate_state.endmethod.method switch_to_at_gate_state.if me->at_gate_state is not bound.create object at_gate_statetype at_gate_stateexporting aircraft = me.endif.me->current_state = me->at_gate_state.endmethod.method switch_to_on_tarmac_state.if me->on_tarmac_state is not bound.create object on_tarmac_statetype on_tarmac_stateexporting aircraft = me.endif.me->current_state = me->on_tarmac_state.endmethod.method switch_to_flying_state.if me->flying_state is not bound.create object flying_statetype flying_stateexporting aircraft = me.endif.me->current_state = me->flying_state.endmethod.ooendclass.
Here we no longer have the constructor creating instances of state objects that may never be used. Instead, each method implementing a switch to a new state checks whether there is a bound reference to the new state, and if one does not exist, it is created. The result is that a state object is not created until the moment it is known that it needs to exist.
Summary
In this chapter, we learned how to avoid unnecessarily creating instances of classes that might never be used. The lazy initialization technique allows us to reduce the wasteful utilization of resources, consuming storage and performing processing only when it is known that an entity will be needed. This is one of the techniques by which we can optimize the performance of the components we create through software design.
Lazy Initialization Exercises
Refer to Chapter 20 of the functional and technical requirements documentation (see Appendix B) for the accompanying ABAP exercise programs associated with this chapter. Take a break from reading the book at this point to reinforce what you have read by changing and executing the corresponding exercise programs. The exercise programs associated with this chapter are those in the 313 series: ZOOT313A and ZOOT313B.