L11: Structuring the system itself

Question 1

MVC

Answer 1

Resembles a widely used architectural design pattern for GUI-based software systems:
- Model
- View
- Controller

Question 2

Why use the MVC?

Answer 2

• Make presentation independent of data
• Allow to compose the presentation
• Switch input/view modes or controllers even during runtime
• Separate concerns/responsibilities (note: it defines what to separate, but not how)

Question 3

Is the MVC connected to other design patterns?

Answer 3

MVC can incorporate many other design patterns:
- Command to pass information between the components
- Decorator to add elements to a view
- Facade to specify interfaces for the individual units
- Factory to specify and create default controllers
- Listeners to react to user interactions and changes
- Observer to update views on model changes
- Strategy to choose between different behaviors

Question 4

What exactly is the model?

Answer 4

Internal representation of information/data:
- Manages data, logic, and rules
- Defines methods for data manipulation
- Manages requests on data state
- Implements business logic

Question 5

What exactly is a view?

Answer 5

A user interface (I/O)
- Displays/represents information from the model
- Accepts input from the user

Question 6

What exactly is the controller?

Answer 6

Unit that links model and view
- Translates inputs into commands for the model or view
- Today, often already integrated into standard libraries

Question 7

Observer: What it does, what is it used for?

Answer 7

Define a one-to-many dependency between objects
- Ensure loose coupling
- When the one object (subject) changes, the many (observers) update automatically
- Notifying multiple dependent objects

Used for
- MVC/GUIs to update views
- Distributed event handling

Question 8

Push method vs pull method

Answer 8

Push method:
- Subjects send necessary data on change
- Less independent (subjects require knowledge about what to send)

Pull method:
- Subjects notify observers that they change
- Observers pull data via subject’s getters
- More independent, but can be inefficient (easier to reuse, but they must identify what changed)

Question 9

Being careful with the observer

Answer 9

• Triggering the update (updating after each operation can cause overhead)
• Managing object deletion (deleting observer/subject dependencies)
• Ensuring consistent subject state before updating
• Deciding what data to send/how to update (push versus pull)