Report-Observer-Pattern.md

-Within one machine of the game, many places need to observe the model for state changes.  For example, when the state of the model changes, the GUI might need to know so it can correctly render the screen or the communications subsystem might need to send a message to another one of the machines in the game.   While we could use the Observer pattern, we really don't want the observers to know where in the model they need to observe.  That would expose a lot of the internals of the model and make our layers pretty tightly coupled. In order to keep things loosely coupled, we've created a variant of the observer pattern that we call Qualified Observer.  Yes, we need observables and observers, but, instead of registering as an observer of a particular object, we register what information the observer is interested in and we'll give it to them no matter what object sources it.  The pieces of information the model can source are objects that implement QualifiedObservableReport (we just call these objects "reports"). In other words, with each update, the model sends on object that is from a subclass of QualifiedObservableReport.  Each observer specifies which of these reports it wants to receive.  With this information, the QualifiedObservableConnector sets up necessary the observer/observable connections.
+Within one machine of the game, many places need to observe the model for state changes.  For example, when the state of the model changes, the GUI might need to know so it can correctly render the screen or the communications subsystem might need to send a message to another one of the machines in the game.   While we could use the Observer pattern, we really don't want the observers to know where in the model they need to observe.  That would expose a lot of the internals of the model and make our layers pretty tightly coupled. In order to keep things loosely coupled, we've created a variant of the observer pattern that we call Report Observer.  Yes, we need observables and observers, but, instead of registering as an observer of a particular object, we register what information the observer is interested in and we'll give it to them no matter what object sources it.  The pieces of information the model can source are objects that implement Report. In other words, with each update, the model sends on object that is from a subclass of Report.  Each observer specifies which of these reports it wants to receive.  With this information, the ReportObserverConnector  sets up necessary the observer/observable connections.
 
-For example, suppose that some place in the view wants to know when the current player has moved.  In other words, it wants to receive ThisPlayerMovedReports from the model.  It must implement QualifiedObserver and register this interest with
+For example, suppose that some place in the view wants to know when the current player has moved.  In other words, it wants to receive ThisPlayerMovedReports from the model.  It must implement ReportObserver and register this interest with
 
 ```java
-QualifiedObservableConnector.getSingleton().registerObserver(viewObject, ThisPlayerMovedReport.class);
+ReportObserverConnector.getSingleton().registerObserver(viewObject, ThisPlayerMovedReport.class);
 ```
 
 The parameters to registerObserver() are the object that wants the information and the class of the report it wants to receive.