DOC PREVIEW
UT Dallas CS 6359 - S17_Chapter_25

This preview shows page 1-2-16-17-18-34-35 out of 35 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 35 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Slide 1What will we learn?GRASP PatternsGRASP Patterns: ControllerGRASP Patterns: Controller ExampleSlide 6GRASP Patterns: ControllerGRASP Patterns: ControllerGRASP Patterns: Bloated ControllerSlide 10Slide 11GRASP Patterns: High CohesionHigh Cohesion: POS ExampleHigh Cohesion: POS ExampleSlide 15High Cohesion: ObservationsPolymorphismPolymorphism: NextGen ExampleSlide 19Polymorphism: Monopoly ExampleSlide 21Polymorphism: Monopoly ExampleSlide 23Slide 24Polymorphism: ObservationsPure FabricationPure Fabrication: NextGen POS ExamplePure Fabrication: Monopoly ExampleSlide 29IndirectionSlide 31Protected VariationsGRASP: Final ThoughtsTakeaways from Chapter 17, 25Next …Object-Oriented Analysis and DesignCHAPTER 17, 25: GRASP PATTERNS1What will we learn?GRASP – More patterns2GRASP Patterns Recall that these are general principles for software design Patterns of design that have been successfully applied We have explored 3:Creator (who creates a new instance)Expert (general principle for assigning responsibilities to objects)Low Coupling (how best to support low dependency, low change impact, high reuse) Now we will explore the remaining six patterns3GRASP Patterns: Controller Problem: What first object beyond the User Interface layer receives and coordinates (“controls”) a system operation? Solution: Assign responsibility to a class representing one of the following choices:Represents the overall “system”, a “root object”, a device that the software is running in, or a major subsystem (these are façade controllers)Represents a use case scenario within which the system event occurs, often called a “Handler”, “Coordinator”, or “Session”. Use the same controller class for all system events in the same use case scenario. Note a “session” is a conversation between the system and an actor, and is often organized in terms of use cases System operations are operations that are performed as the result of a major system (input) event, like hitting “Submit” on a form or pressing the “End Sale” button in the POS A Controller is the first object (beyond any User Interface object) that is responsible for receiving or handling the event and generating the operation4GRASP Patterns: Controller Example During Analysis, could have a conceptual class called “System” that owns system operations – but this may not directly translate to a similar class in design …5SystemendSale()enterItem()makeNewSale()makePayment(). . .6Which class of object should be responsible for receiving this system event message?It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.The controller is a kind of "facade" onto the domain layer from the interface layer.actionPerformed( actionEvent ): ???: Cashier:SaleJFramepresses buttonenterItem(itemID, qty)UI LayerDomain Layersystem operation messageGRASP Patterns: Controller For the POS example, we could assign the operations of enterItem and endsale to the Register object, or we could create a POSSystem object, or create ProcessSaleHandler, ProcessSaleSession classes and assign the task of handling the system operations to them The Controller is a delegation principle; since we don’t want the objects in the UI layer to do application logic, the Controller principle helps to summarize the choices the developer has to decide which Domain object will receive the work requestsChoosing a handler for system events May have different controller classes for different use cases Make sure the controller you specify delegates the work, and does not do it itself. It coordinates work, controls activity7GRASP Patterns: Controller Façade controllers (one class to represent all system operations) are useful when there are not too many system events, or if the UI classes cannot redirect system event messages to specific controllers (message-processing). Individual use case controllers are good if the façade controller is becoming “bloated” with responsibilities, implying high coupling Controllers are often seen in web UI, but the principle of Model-View Separation does still applyThis is the Model-View-Controller Note that even if you decide that individual handlers will be responsible for particular use cases, you still need an overall “main” function to initialize everythingBook shows an example of Java code where the Register handles the enterItem system operation; the Register and client UI still need to be instantiated by something8GRASP Patterns: Bloated Controller A controller is “bloated” if it is doing too much: A single controller receiving too many system events, the controller itself is performing the logic to process the system event (acting like an Expert), the controller has many attributes and maintains significant amounts of information Think of the controller as being the “team manager” – delegates work to the experts Again, the UI layer does not handle system events! It delegates responsibility for handling events to the Application or Domain Layer, where a controller takes over (and probably delegates the work to other Domain Objects)Not a good idea to have the UI object directly delegate the work to the Domain Object – this would lead to business logic being used in the UI Layer. See following slides.910Cashier:SaleJFrameactionPerformed( actionEvent ):Sale1: makeLineItem(itemID, qty)UI LayerDomain LayerIt is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.Business logic is embedded in the presentation layer, which is not useful.SaleJFrame should not send this message.presses button11actionPerformed( actionEvent ):Register: Cashier:SaleJFramepresses button1: enterItem(itemID, qty):Sale1.1: makeLineItem(itemID, qty)UI LayerDomain Layersystem operation messagecontrollerGRASP Patterns: High Cohesion Problem: How to keep objects focused, understandable, and manageable, and as a result support Low Coupling? Solution: Assign a responsibility so that cohesion remains high. In other words, only assign strongly related responsibilities to an object. An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion. Low cohesion classes:Complicated, hard to understandHard to reuseHard to maintainBrittle; easily affected by change12High Cohesion: POS Example The POS system needs to handle a makePayment system event; if we are using the


View Full Document

UT Dallas CS 6359 - S17_Chapter_25

Documents in this Course
Lecture2

Lecture2

63 pages

Lecture3

Lecture3

49 pages

Lecture4

Lecture4

48 pages

Lecture5

Lecture5

47 pages

Lecture6

Lecture6

45 pages

Lecture7

Lecture7

63 pages

Lecture8

Lecture8

77 pages

Lecture9

Lecture9

48 pages

Lecture10

Lecture10

84 pages

Lecture11

Lecture11

45 pages

Lecture12

Lecture12

134 pages

Lecture13

Lecture13

62 pages

Lecture14

Lecture14

76 pages

Project

Project

2 pages

Chapter_1

Chapter_1

25 pages

Load more
Download S17_Chapter_25
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view S17_Chapter_25 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view S17_Chapter_25 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?