1 / 20

Behavioral Design Pattern

Behavioral Design Pattern. Tutorial 9. Model-View-Controller. “The holy triad”. The Model-View-Controller pattern (MVC). An extension of the observer pattern to include also elements of control. Very much in use when implementing GUI Most of Swing is implemented using MVC.

hetal
Download Presentation

Behavioral Design Pattern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Behavioral Design Pattern Tutorial 9

  2. Model-View-Controller “The holy triad”

  3. The Model-View-Controller pattern (MVC) • An extension of the observer pattern to include also elements of control. • Very much in use when implementing GUI • Most of Swing is implemented using MVC. • Common also in other toolkits • Origin: SmallTalk-80 • Was later refined to Morph. • Today: the common trade.

  4. MVC elements • The model • Contains the actual data to be viewed and controlled. • Interacts with the application’s logic. • The View • Displays the model, refreshes when notified. • Fetches the data from the model. • The controller • Changes or activates the model. • Might cause, indirectly, a refresh of the view.

  5. MVC diagram Controller View Fetch data Control Notify Model

  6. MVC sequence Controller invoked Display changes Controller View Fetch data Affect the model Notify Model

  7. MVC classes and interfaces View Controller View2Model + notify() 0..* views 1 model model Model Model2Control + controlThis() + modifyThat() Model2View + addView() + removeView() + getData()

  8. MVC interfaces (1) • Model to Controller • Defines the operations and manipulations exposed to the controller. • Derives from the model’s functionality. • Model to View • Allows attaching and detaching views. • Defines the data exposed to the view • Many times it will be similar to the one the controller manipulates or affects

  9. MVC interfaces (2) • View to Model • Allows notifying the view that a change occurred. • Several options: • No parameters – all the data is fetched from the model. • Event parameter – relevant data is sent as parameter. • Name parameter – the name of the attribute that changed is sent as parameter. Relevant data is then fetched. • Used with some Java beans mechanisms. • There can be several interfaces or variations, according to the model

  10. Finding MVC interfaces • Model to Controller • Model data’s setter • Application’s functionality • Methods used by actors • Model to View • Model data’s getters • Actor class operations • The view itself • Usually from the customer’s requirements.

  11. The model and the application • In the MVC framework, the model is both a part of the GUI’s process and the logic itself. • It must notify the view in order to make it work. • The application is the model. • In real life, we might not have such luxury. • It forces the logic to be aware of the view. • Alternative: the model acts as a mediator between the GUI and the application.

  12. MVC and application View Controller Model Application

  13. The Command Pattern OOP closures

  14. The Command Pattern • The problem: how to pass code as a parameter? • Some OOP languages support closures directly, so the question does not arise. • SmallTalk, Python, CLOS… • Partial solution: function pointers. • Very common in C++/STL • Can be problematic • The “clean” OOP solution: command objects.

  15. The Command Pattern classes Command +execute() Client Receiver Usually a button Or some other controller The “env.” to Perform the command on. ConcreteCmd +execute()

  16. Acquiring the receiver • How does the command acquires its “target”? • Constructor parameter • Can be limiting • Parameter to “execute()” • Access some “current” pointer • “Application.getCurrentDocument()” • Dynamic inner class visibility • The receiver is the “this” object of the outer class. • A bit like real closures.

  17. Some non-GUI uses of Commands • Undo/redo • Send “orders” to recipients • Even over the net! • Stages in some complex algorithm or protocol • Composite commands can be macros. • Map strings to commands to get • A quick-and-dirty scripting lang. • A parser • XML parser example

  18. Commands and MVC • Commands can act as intermediate controllers to some complex and large model • The model is not necessarily a single class! • Instead of exposing a large interface, let a set of commands be used by the controllers. • A clean interface is not always used; in this case, it is not clear which methods are for the controllers. • Maybe the model can even be hidden! • As a rule, set of commands can be a handy alternative to inconvenient interfaces

  19. MVC with commands View Op1 Controller Op1Cmd Model Op2 Controller Op2Cmd Op3Cmd Op3 Controller

  20. Adding GUI example Using MVC and commands for the outline editor

More Related