Design Patterns Source Design Patterns Erich Gamma Richard

Design Patterns Source: “Design Patterns”, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides And http: //java. sun. com/blueprints/patterns Created By Eshcar Hilel

Agenda • Design Patterns - Why? • Model-View-Controller Pattern – What Is the Problem? – Solution, Structure, Responsibilities – Class Diagram • MVC variants examples Design Patterns 2

Design Patterns - Why? • Designing OO software is hard • Designing reusable OO software – harder • Experienced OO designers make good design • New designers tend to fall back on non-OO techniques used before • Experienced designers know something – what is it? Design Patterns 3

Design Patterns - Why? • Expert designers know not to solve every problem from first principles Analogy II – Telenovela!! • They reuse solutions • These patterns make OO designs more flexible, elegant, and ultimately reusable Analogy I - Novelists and playwrights: “Tragically Flawed Hero” (Macbeth, Hamlet. . . ) “The Romantic Novel” Design Patterns 4

Two Major Principles of Object-Oriented Design: Dynamic binding, polymorphism. . . • Program to an interface, not an implementation. • Favor object compositions over class inheritance. See more of this in… OOD White-box reuse vs. Black-box reuse Design Patterns 5

Model-View-Controller Pattern • MVC consists of three kinds of objects: – Model – the application object – View – UI (screen presentation) – Controller – defines the way the UI reacts to user inputs Design Patterns 6

MVC – What Is the Problem? • The same enterprise data needs to be accessed when presented in different views: e. g. HTML, JFC/swing, XML • The same enterprise data needs to be updated through different interactions • Supporting multiple types of views and interactions should not impact the components that provide the core functionality of the enterprise application Design Patterns 7

MVC – Solution • Separate core business model functionality from the presentation and control logic that uses this functionality • Allows multiple views to share the same enterprise data model • Makes supporting multiple clients easier to implement, test, and maintain Design Patterns 8

The MVC pattern • The Model is the actual internal representation • The View (or a View) is a way of looking at or displaying the model • The Controller provides for user input and modification • These three components are usually implemented as separate classes 9

MVC – Responsibilities • Model - the model represents enterprise data and the business rules that govern access to and updates of this data • View -the view renders the contents of a model. It accesses enterprise data through the model and specifies how that data should be presented • Controller - the controller translates interactions with the view into actions to be performed by the model Design Patterns 10

MVC Structure Design Patterns 11

The Model • Most programs are supposed to do work, not just be “another pretty face” – but there are some exceptions – useful programs existed long before GUIs • The Model is the part that does the work--it models the actual problem being solved • The Model should be independent of both the Controller and the View – But it provides services (methods) for them to use 12 • Independence gives flexibility, robustness

The Controller • The Controller decides what the model is to do • Often, the user is put in control by means of a GUI – in this case, the GUI and the Controller are often the same • The Controller and the Model can almost always be separated (what to do versus how to do it) • The design of the Controller depends on the Model • The Model should not depend on the Controller

The View • Typically, the user has to be able to see, or view, what the program is doing • The View shows what the Model is doing – The View is a passive observer; it should not affect the model • The Model should be independent of the View, but (but it can provide access methods) • The View should not display what the Controller thinks is happening 14

Combining Controller and View • Sometimes the Controller and View are combined, especially in small programs • Combining the Controller and View is appropriate if they are very interdependent • The Model should still be independent • Never mix Model code with GUI code! 15

Separation of concerns • As always, you want code independence • The Model should not be contaminated with control code or display code • The View should represent the Model as it really is, not some remembered status • The Controller should talk to the Model and View, not manipulate them – The Controller can set variables that the Model and View can read 16

Example Control Flow in MVC • User interacts with the VIEW UI • CONTROLLER handles the user input (often a callback function attached to UI elements) • CONTROLLER updates the MODEL • VIEW uses MODEL to generate new UI • UI waits for user interaction

Three Tier Model Design Patterns 18

Problems • Problems of translation: – Business logic bleeds into the Controller. • Problems of the pattern: – Excessive coupling between the Model and View and the Model and Controller. – Frozen interfaces are hard to manage!

References • Wikipedia • Fox, Christopher. Introduction to Software Engineering Design. Boston: Pearson, 2006. • Burbeck, Steve. Applications Programming in Smalltalk 80(TM): How to use Model-View-Controller (MVC). http: //st-www. cs. uiuc. edu/users/smarch/st-docs/mvc. html • Morse, Scot F. Introducing Application Design and Software Engineering Principles in Introductory CS Courses: Model-View-Controller Java Application Framework.