Student_Answers_Chapter_14.doc

Suggested answer for Exercise 14.2A simple-minded implementation of the structure in Figure 14.8 is given below. It is apparent from the code that the abstract supplier interface has not been modified when the new abstract supplier interface was added, and hence that the module is closed. public interface AbstractSupplier public void operation() ;public interface NewAbsSupplier extends AbstractSupplier public void newOperation() ;public class ConcreteSupplier implements AbstractSupplier public void operation() System.out.println(ConcreteSupplier:operation() called) ; public class NewConcSupplier implements NewAbsSupplier public void operation() System.out.println(NewConcSupplier:operation() called) ; public void newOperation() System.out.println(NewConcSupplier:newOperation() called) ; public class Client AbstractSupplier supplier ; public Client(AbstractSupplier s) supplier = s ; public void doOperation() supplier.operation() ; public class NewClient NewAbsSupplier supplier ; public NewClient(NewAbsSupplier s) supplier = s ; public void doOperation() supplier.operation() ; public void doNewOperation() supplier.newOperation() ; Suggested answer for Exercise 14.5Observer Document/View class Observer class CView class ConcreteObserver class CMyView Observer.Update() CView.OnDraw() class Subject class CDocument class ConcreteSubject class CMyDoc Subject.Attach() CSubject.AddView() Subject.Detach() CSubject.RemoveView() Subject.Notify() CSubject.UpdateAllViews() Subject.SetState() CSubject.SetStateInfo() Subject.GetState() CSubject.GetStateInfo() This table shows that virtually every feature of Observer can be mapped into a corresponding feature of Document/View. There are two significant differences between the two patterns. Concrete observers hold a reference to their subjects, whereas in Document/View all references between views and documents are maintained at the abstract level. In practice, this is not very significant, and it can be argued that Document/View supports the association in Observer, as it is simply inherited from the bidirectional association linking the abstract classes. Another difference is the complexity of the update operation in Document/View. In Observer, the Notify() operation in the subject calls Update() in the observer, which in turn calls GetState(). In Document view, notification calls the OnUpdate() function, whereas it is a different function, OnDraw() which retrieves the document state. Again, however, it can be argued that Document/View does support the interaction defined in Observer, albeit in a not immediately straightforward way. There are therefore strong grounds for regarding Document/View as an instantiation of the Observer pattern. Suggested answer for Exercise 14.6This question should refer to the document/view architecture in addition to MVC. Figure 14.18 shows an MVC interaction where notification takes place every time the state of the subject (here the model) changes. In the document/view architecture, one option would be to have the operation CMyDoc:SetStateInfo() call OnUpdate() every time it are called. This approach has the advantage that client objects which are updating the document dont have to remember to call the notification operation, and the views are guaranteed to be automatically and promptly made consistent with the document or model state. On the other hand, if a number of consecutive updates are applied to a model, each will cause the corresponding views to be updated independently of the others. It may be sufficient to update the views once, at the end of this sequence of updates, and updating more frequently may be unacceptably inefficient. The alternative would be for objects which update the document to call UpdateAllViews() in the document/view architecture when the update is finished. This allows updates to wait until a sequence of changes has been made, but places an additional responsibility on client objects, thus complicating their implementation and