Recall: The MVC Architecture

• Controller: takes input from the user and decides what to do

• View: knows how to display the interface to the user

• Model: the domain information that the program manipulates

Controller

• Glue of the system

• Controls how and when the model is used

• Controls what must be shown to the view and when (in some cases)

• Controls what action must be taken when user interacts with system (in some cases)

• Controls the sequence of operations in an application(in some cases)

Model, View and Controller relative to each other

• Model: Offers actual operations

  • Oblivious to when they are needed and how to present results

• View: Presents results

  • Oblivious to how they are produced or what to do next

• Controller: Delegates to model and view

  • Oblivious to how model completes the operations or how specifically the view shows output

Ignorance is bliss

An example: PyramidSolitaireController

• “Controls” the game

• Uses the model and the view in specific sequence

  • Determines when to ask for user input
  • Determines when to use which operation of model
  • Determines when to show output to the view

• The sequence of the game is determined by the controller, not the user

Synchronous Controllers

• Determines the sequence of operations of the system

• Determines when and how the system interacts with something external

• Suitable for pre-baked “rules-based” applications, like games

• Challenges:

  • How to truly separate controller from view so each one is replaceable?

  • What to do when system is reactive in nature (to user input)?

    • User interaction decides program behavior, not controller

    • Examples: Microsoft Word, IntelliJ

Asynchronous Controllers

• Controller gets control when external input is given

• Controller methods are called as a response to external input

• Such methods in the controller are called callbacks

• GUI programs typically work this way

  • User clicks a button, moves the mouse ⇒ a controller method is called

  • In OO GUIs, callbacks are often wrapped in classes called listeners

• Look at MVCExample code

Who is the puppeteer?

• Who creates the controller, model, view objects and sets the program in motion?

• For standalone Java program: the main method

public class MainRunner {
   public static void main(String[] args) {
     IModel theModel = makeAModel();
     IView aView = makeAView();
     IController theController = makeController(theModel, aView);
     theController.go();
   }
}

Simple input and output

• Printing to console System.out.print

• Reading from keyboard Scanner

• How to we test this (using a tester, not a human)?

Mocks

• A component that can “replace” an actual component

  • For testing purposes

  • As a placeholder for simultaneous development (also called a stub)

• Design that facilitates replacement promotes mocking

  • Good encapsulation ⇒ fixed role ⇒ easier to replace

  • Design by interface ⇒ Not dependent on specific implementation

  • Refer to components using interfaces ⇒ work with any implementation of that interface

  • Mock implements actual interface, but does so simply or to enable testing

• Use mocks to

  • Test components that otherwise require I/O

  • Emulate a component that is being concurrently designed/implemented