Observer, Interpreter and Iterator Pattern

Starting Point Analysis

Requirement in this phase

1. Cyclic dependence should be disallow between the spreadsheet cells. This cyclic dependence may spread over several cell expressions. For example: $1$1=$0$0+1 $0$0=2*$2$2 $2$2=$5%5 $5$5=$1$1+1.
2. When a user assign an expression to a cell, in which a cyclic dependence is detected. It is more helpful to inform users the expression cycle rather than say there is a cycle.
3. Since one cell could depend on other cells, some other cells may depend on this cell in turn. When one cell is updated, many cell that directly or indirectly related to this cell should also be updated. How to solve this problem nicely.

1. keep all the dependence relationship in the SpreadSheet class
2. keep the individual dependence relationship in the Data class.

The steps to update a cell's tree, we call this cell C :

1. For each CellNode in the tree, check whether it directly or indirectly refers C. Indirect reference means one's child or grandchild refers back to C.
2. If no cyclic dependence
   1. update all the old child's parent
   2. update the current cell's children.
   3. update the present children's parent.
   4. If all the present children have a numeric value, then evaluate the current cell. Then notify all the parents to update value. all the notified parents will recursively notifies there own parents.
3. return updated information.

Iterator Pattern Overview

1. Intent

   Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

2. Structure

   

3. Participants

   • Iterator
   • defines an interface for accessing and traversing elements.
   • ConcreteIterator
     • implements the Iterator interface.
     • keeps track of the current position in the traversal of the aggregate.
   • Aggregate
     • defines an interface for creating an Iterator object.
   • ConcreteAggregate
   • implements the Iterator creation interface to return an instance of the proper ConcreteIterator.

UML Design in this phase

Steps in this phase

1. step 1: To find whether there is a cyclic dependence, we have to find all the cell references at first in the tree, which means we have to traverse the tree. To simplify the load of Data class, I sperate this traverse mechanism from Data class. That is why I use the Iterator Pattern. Using this pattern, a client can get all the cell references without knonwing the structure of a tree. So in this step, I modified the Tree class and add a TreeIterator class, which returns the next cell reference in a tree instance.
2. step 2: When we inform a user that a cyclic dependence is happened, it is helpful if we can tell the user all the related expressions in some order. To remember a cell's express, we can store the expression string as a member of Data class. Since the Data class already have a tree reference, we can use the Interpreter Pattern again to reconstruct the expression. To do this, I add a __repr__ method to each TreeNode classes. After these two steps, the Tree class looks like this.
3. step 3: Implement the Data class using the strategy as mentioned. When a cell is changed, it will notify all its parents to update. The parents is the observers, and the cell is subject. We parents get the notification, they will query the cell state. This is the Observer pattern in essence, although we cannot show the observer pattern structure in the class diagram. This is the reason I call the method notify(). This also tells us that we should bear the essence of each pattern in mind, not the stucture.

After these steps, we have our prototype 7 now.

References