1 of 19

Lecture 8

Observers, Adapters & MVC

Joey Freund, CSC301, Fall 2014

2 of 19

Observer Design Pattern

  • We want to take an action whenever something happens to some object.
  • For example:
    • Send confirmation email, when an order is paid.
    • Get fresh data, when you swipe-down the top of your news-feed on FB app.
    • Refresh the screen, when new data is available.

3 of 19

Observer Design Pattern

  • Let’s go through an example.

4 of 19

Observer in Java

  • Issues with our first implementation:
    • In order for class A to be Observable, it needs to extend the observable class. What if we need class A to extend some other class B?
    • The Observer interface requires us to do casting, whenever we observe a change.
      • It is another thing that can go wrong at runtime.
      • The implementation code is less clean.

5 of 19

Observer in Java

  • Issues with our second implementation:
    • We need write more code. Specifically, code that is already implemented in the Observable class.

6 of 19

Observer in Java

  • An issue with observers:
    • If an observer is not removed from the observable, it will never get garbage collected.
    • Can lead to memory leaks.
    • This issue exists in any language that has automatic garbage collection.
    • Known as the lapsed listener problem.
    • One solution is: Weak references.

7 of 19

Terminology

  • A few names:
    • Observer
    • Listener
    • Publish-Subscribe
  • The concept is the same:
    • Define an interface for handling changes/events.
    • The two involved objects depend on that interface, not on each other.

8 of 19

Back To Our Example

  • Let’s introduce a new requirement ...
  • When the application observes a change in a stock, it would like to get the old price, as well as the new price.

9 of 19

New Requirement

  • We can handle with it in many ways:
    • Make the application store every price update in some sort of a database that it can query.
      • Very heavy solution.
    • Make the application store just the last price update it has seen for each stock.
      • Incohesive (we just added a new responsibility).
    • Create an adapter ...

10 of 19

The Adapter Design Pattern

  • Simple and intuitive design pattern, that can really clean up your code.
    • Component1 generates data in format1.
    • Component2 consumes data in format2.
    • The adapter consumes data in format1, and converts it to format2.
  • The concept of adapters should seem familiar.

11 of 19

Observers & Adapters

  • Observers and adapters are extremely common patterns.
  • They are both techniques that help us decouple our system’s components.
  • If we are already talking about decoupling, let’s talk about MVC...

12 of 19

MVC

  • Model
    • You data objects.
    • Specific to your domain (e.g. Train company in a trip-advising application, or Stocks in a stock market application).
    • Usually kept very simple - They just encapsulate a number of attributes/properties in a single object.

13 of 19

MVC

  • View
    • The representation of the data.
    • What the user sees (e.g. HTML page, the GUI of your mobile app, a text-based console).
    • Note: The user is not necessarily a human. For example, programs want to view the data using some text format (e.g. XML, or JSON)

14 of 19

MVC

  • Controller
    • Controls the flow of the application.
    • Connects between the model and the view.

15 of 19

MVC

  • Let’s see an example.
  • Notice that the Model and View are independent of one another.

16 of 19

Our MVC Example

  • The Model
    • Generates stock-updated events.
    • Is accessed/modified using a StockDAO implementation.
  • The View
    • Generates pause-clicked or resume-clicked events.
    • Listens to stock-updated events.

17 of 19

Our MVC Example

  • The Controller
    • Uses an adapter to connect the stock-updated events generated by the model to the stock-updated events consumed by the view.
    • Listens to pause/resume click events, and pauses/resumes updating the model.

18 of 19

Our MVC Example

  • Our Stock Market implementation
    • An in-memory implementation of a StockDAO.
    • Observes each stock for changes.
    • Generates stock-updated events for all stocks.
      • An external class can observe our stock market implementation, instead of the individual stocks.

19 of 19

MVC

  • MVC is an extremely popular pattern.
    • It applies to many practical use cases (GUI applications, web servers, web clients, etc.)
    • It describes a general strategy, and can be implemented differently in different use cases.
    • We use other patterns/techniques (e.g. observer, adapter, etc.) to decouple the Model, View and Controller.