# 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

# An example: simple games

• “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