# Following the Writer's Path to the Dynamically Coalescing Reactive Chains Design Pattern
## 13 Applying the Pattern
### Constructing a Solution
#### 13.2.3 Augmentation Incorporation  
In the augmentation incorporation phase, we must perform the three application augmentation tasks AN1, AN2, and AN3 given in Section 11.4. In this phase, we take the software mechanisms developed in Section 13.2.2 above and incorporate them into the GUI application.  
(AN1) How can we augment the C#/.NET GUI application to construct the dependency graph at or before startup?  
A C# GUI is an instance of the class Form or one of its subclasses. This class defines an event handler method form_start() that executes during the Form's instantiation--after it instantiates all its controls but before it renders the form to the display. We modify this method to incorporate the construction of the dependency graph into the event handling system.  
To designate a Form as reactive, we define a C# interface named iUpdatable that declares a form_start() method. We require that any class implementing iUpdatable defines an appropriate method body for form_start(). Using the mechanisms developed in Section 13.2.2 above, this method must examine the GUI and construct the initial dependency graph as an object in the Form subclass.  
How can we augment the C#/.NET GUI application to use the dependency graph to coalesce the processing of chains of events into a \"large-grained event\"?  
As discussed in Section 13.2.1, we define an interface iReactive that declares a special event handler method reactiveUpdate(). Any Control subclass that implements iReactive must define reactiveUpdate() to have appropriate behavior (which may include the behavior of the built-in event handler method Update()). The reactive control class must also override the built-in Update() method so that it calls the reactiveUpdate() method instead of the control's standard event handling code.  
If a reactive control responds to an external (e.g., user interaction) event, then the built-in event handler method Update() must detect the external event and redirect its handling to the augmented event handler method reactiveUpdate(). Based on the constraints in the dependency graph, this method constructs a sequence of updates of the dependent controls. Then it explicitly invokes the reactiveUpdate() methods of each control in the sequence. This process thus propagates the effects of one external event throughout the GUI. From the standpoint of the built-in event handling system, this whole sequence of updates is executed as one \"large-grained\" event in the augmented GUI application.  
How can we augment the C#/.NET GUI application to update the dependency graph when the component architecture changes during operation?  
We must modify the application so that, at the end of the update cycle, it checks whether the GUI structure has changed since the beginning of the cycle (as described in Section 11.4.2 above). If the GUI has changed, we must rebuild the dependency graph (using mechanisms from Section 11.4.2). We add this check to the augmented event handler reactiveUpdate (as described above). It must do this immediately after inferring the execution order from the dependency graph and calling the reactiveUpdate() methods of the dependent controls.