Student_Answers_Chapter_14.doc

1、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 int

2、erface AbstractSupplierpublic void operation() ;public interface NewAbsSupplier extends AbstractSupplierpublic void newOperation() ;public class ConcreteSupplier implements AbstractSupplierpublic void operation() System.out.println(“ConcreteSupplier:operation() called“) ;public class NewConcSupplier

3、 implements NewAbsSupplierpublic void operation() System.out.println(“NewConcSupplier:operation() called“) ;public void newOperation() System.out.println(“NewConcSupplier:newOperation() called“) ;public class ClientAbstractSupplier supplier ;public Client(AbstractSupplier s) supplier = s ;public voi

4、d doOperation() supplier.operation() ;public class NewClientNewAbsSupplier 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 O

5、bserver 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

6、.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, whe

7、reas 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 abs

8、tract 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 fun

9、ction, 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 Observe

10、r 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 opti

11、on 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 promptl

12、y 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,

13、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 running the risk that updates might, through errors of omission, not be carried out. Because of the role of the controller in MVC, this approach could not be adopted without significant change to the structure.