This example is about Observer/Observable as well as a review of MVC

Reason to use:
- O Wants to react to changes in state of object M without having
  to burden M with what O needs from M to correctly react.
- Allow many such O's to independently subscribe to M for
  an update when M changes.

Observer/Observable Design Pattern
- https://www.oodesign.com/observer-pattern.html
  NOTE: ConcreteObservableA and ConcreteObservableB are mislabelled,
  they should be 
  ConcreteObserverA and ConcreteObserverB.

- This is an example of pulling state vs pushing state.
- The Observable is not responsible for understanding the Observer. 
- The Observable just knows that the Observer understands update(). 

- The Observer understands the Observable and pull state from it.

- We noted that the Java api includes Observer/Observable already...
    https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Observer.html
    https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Observable.html

- In class we built the guessgame package where we
  built and used a modification of the design pattern.

- We built both the framework code (Observer and Observable)
  and consumed it 
  - ConcreteObserver=the views 
  - ConcreteObservable=the GuessGame model
  - We actually did not have to build Observer and Observable since
    they are already part of the Java API.

- The framework code we built is similar to that of the Java api.
  We built the Observer as an interface 
  and the Observable class and then used them in guessgame.

https://sourcemaking.com/design_patterns/observer

