As in MVC views are dependent on their models. Views can know about the models they represent but a model must not require knowledge of the views which may be on it. A model must be entirely independent of its view. This means that implementing a view for a particular object should not require any modification of that object's behaviour. This leaves us with the question, "How does the view know when the model has changed?". There are several ways of dealing with this problem.
What is needed is a coordination mechanism for the view and model. This coordinator can tell when some action will cause the value of the view to be changed. Sensing that the model has changed, the coordinator tells the view which takes the appropriate action. Since the coordinator forms a much used link between the model and view it must be light weight.
A constraint satisfaction system such as the Filters Paradigm [Ege, 1986] [Grossman and Ege, 1987] is one such system. Filters combines light and heavy weight constraints (filters and logic) to coordinate user-object and object-object interaction respectively. Constraint Hierarchies [Boming et al., 1987] provides more complete but expensive constraint specification. Both are built on top of ThingLab and allow the user to explicitly define what the interactions between entities are.
Another approach to this problem is the use of encapsulators [Pascoe, 1986]. An encapsulator is an object which surrounds another object intercepting all messages to it. In this way, the encapsulator can sense when a "significant" change occurs and directly inform interested objects. In both solutions a nice way of specifying what constitutes a significant change remains a challenge.