# Following the Writer's Path to the Dynamically Coalescing Reactive Chains Design Pattern
## 13 Applying the Pattern
### Constructing a Solution
#### 13.2.2 Augmentation Development  
In the augmentation development phase, we must perform the three design and implementation tasks AD1, AD2, and AD3 given in Section 11.4. In this phase, we use the results of the augmentation analysis above to design and implement the mechanisms. We then incorporate the resulting mechanisms into the GUI application as described in Section 13.2.3.  
* How can we design and implement a mechanism for a C#/.NET GUI application to differentiate between the components to be included in and excluded from the dependency graph?  
We require that all reactive control objects implement the iReactive interface as described in Section 13.2.1 above. We then develop a mechanism (e.g., a function) that uses the C# reflection facilities to determine whether or not an object implements the iReactive interface. (If an object does, it must be included in the dependency graph; if it does not, it must be excluded from the dependency graph.)  
* How can we design and implement a mechanism to detect whether a C#/.NET GUI application's component architecture or the dependencies among the components have changed?  
To determine whether the GUI has changed, we develop a mechanism to store a snapshot of the GUI's structure at the beginning of an update cycle (as defined in Section 13.2.3 below). The snapshot consists of the dependency graph, where each node has a reference to its associated control object. At the end of the update cycle, the mechanism must check whether the GUI structure has changed since the beginning of the cycle. In particular, it must detect GUI changes that modify existing dependencies or add new ones.  
To determine whether there are changes in the dependencies, the mechanism must examine each reactive control. If that control did not appear in the previous snapshot, then the dependency graph is no longer valid. (To compare two control objects, a C#/.NET program checks if they have the same name and type.) If that control did appear in the previous snapshot and any of its dependencies have changed, then the dependency graph is no longer valid. To check whether a control's dependencies have changed, the mechanism examines the control's attributes and methods using C#'s reflection facilities. If any control appears in the previous snapshot but not in the current GUI, then the dependency graph is no longer valid. If nothing has changed from the previous snapshot, then the dependency graph remains valid. If the dependency graph is no longer valid, then it needs to be rebuilt.  
* How can we design and implement the mechanism to construct the dependency graph initially and to reconstruct it when needed?  
As discussed in Section 13.2.1 above, a.NET GUI consists of a hierarchical collection of control objects. A C# program can iterate through this collection and examine each control using C#'s reflection facilities. If some control object C implements the iReactive interface (meaning it should be included in the dependency graph), then the mechanism inserts a new node for C into the dependency graph. For every other control that depends on C, the mechanism inserts a directed edge from that node to C's node.  
The algorithms are essentially the same for the initial construction of the dependency graph and for the graph's reconstruction because of a change in the GUI's structure. The reconstruction is different in that it only needs to iterate through the controls referenced by the previous dependency graph.