So#ware(Engineering( (GRASP(Paerns(ps.informatik.uni-tuebingen.de/teaching/ss15/se/10_grasp.pdf ·...
63
So#ware Engineering GRASP Pa1erns Klaus Ostermann So#ware Engineering 1
Transcript of So#ware(Engineering( (GRASP(Paerns(ps.informatik.uni-tuebingen.de/teaching/ss15/se/10_grasp.pdf ·...
So#ware Engineering GRASP Pa1erns
Klaus Ostermann
So#ware Engineering 1
GRASP Pa1erns
So#ware Engineering 2
} Object Design: } “A#er idenBfying your requirements and creaBng a domain model, then add methods to the so#ware classes, and define the messaging between the objects to fulfill the requirements.”
} But how? } What method belongs where? } How should the objects interact? } This is a criBcal, important, and non-‐trivial task
GRASP Pa1erns
So#ware Engineering 3
} The GRASP pa1erns are a learning aid to } help one understand essenBal object design } apply design reasoning in a methodical, raBonal, explainable way.
} This approach to understanding and using design principles is based on pa1erns of assigning responsibili*es
GRASP -‐ ResponsibiliBes
So#ware Engineering 4
} ResponsibiliBes are related to the obligaBons of an object in terms of its behavior.
} Two types of responsibiliBes: } knowing } doing
} Doing responsibiliBes of an object include: } doing something itself, such as creaBng an object or doing a
calculaBon } iniBaBng acBon in other objects } controlling and coordinaBng acBviBes in other objects
} Knowing responsibiliBes of an object include: } knowing about private encapsulated data } knowing about related objects } knowing about things it can derive or calculate
Design pa1erns in architecture } A pa#ern is a recurring soluBon to a standard problem, in a context.
} Christopher Alexander, professor of architecture… } Why is what a prof of architecture says relevant to so5ware?
} “A pa1ern describes a problem which occurs over and over again in our environment, and then describes the core of the soluBon to that problem, in such a way that you can use this soluBon a million Bmes over, without ever doing it the same way twice.”
Pa1erns in engineering } How do other engineers find and use pa#erns?
} Mature engineering disciplines have handbooks describing successful soluBons to known problems
} Automobile designers don't design cars from scratch using the laws of physics
} Instead, they reuse standard designs with successful track records, learning from experience
} Should so5ware engineers make use of pa#erns? Why? } Developing so#ware from scratch is also expensive
} Pa1erns are a form of reuse of so#ware design
DefiniBons and names } Alexander: “A pa#ern is a recurring soluBon to a standard problem, in a context.”
} Larman: “In OO design, a pa#ern is a named descripBon of a problem and soluBon that can be applied in new contexts; ideally, a pa1ern advises us on how to apply the soluBon in varying circumstances and considers the forces and trade-‐offs.”
Basic Pa1ern Principles
So#ware Engineering 8
} Pa1erns are never invented; they are found } they codify exisBng tried-‐and-‐true knowledge, idioms, and principles
} the more honed and widely used, the be1er
} Pa1erns give a name to an idea!
Fred: "Where do you think we should place the responsibility for creaAng a SalesLineltem? I think a Factory." Wilma: "By Creator, I think Sale will be suitable." Fred: "Oh, right -‐ I agree."
GRASP } Name chosen to suggest the importance of grasping fundamental principles to successfully design object-‐oriented so#ware
} Acronym for General Responsibility Assignment So#ware Pa1erns } (technically “GRASP Pa1erns” is hence redundant but it sounds be1er)
} Describe fundamental principles of object design and responsibility
} Expressed as pa1erns
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
InformaBon Expert
So#ware Engineering 12
} Problem: What is a general principle of assigning responsibiliBes to objects?
} SoluBon: Assign a responsibility to the informaBon expert } the class that has the informaBon necessary to fulfill the responsibility
} Start assigning responsibiliBes by clearly staBng responsibiliBes!
} For instance, in a POS applicaBon a statement might be: “Who should be responsible for knowing the grand total of a sale"?
InformaBon Expert
So#ware Engineering 13
} What informaBon is needed to determine the grand total?
} Sale is the informaBon expert for this responsibility.
InformaBon Expert
So#ware Engineering 14
} What informaBon is needed to determine the line item subtotal?
InformaBon Expert
So#ware Engineering 15
} To fulfill the responsibility of knowing and answering its subtotal, a SalesLineltem needs to know the product price.
} The ProductSpecificaBon is an informaBon expert on answering its price; therefore, a message must be sent to it asking for its price.
InformaBon Expert
So#ware Engineering 16
} To fulfill the responsibility of knowing and answering the sale's total, three responsibiliBes were assigned to three design classes of objects
InformaBon Expert: Final Design
So#ware Engineering 17
InformaBon Expert: Discussion
So#ware Engineering 18
} Expert usually leads to designs where a so#ware object does those operaBons that are normally done to the inanimate real-‐world thing it represents } a sale does not tell you its total; it is an inanimate thing
} In OO design, all so#ware objects are "alive" or "animated," and they can take on responsibiliBes and do things.
} They do things related to the informaBon they know.
InformaBon Expert: Discussion
So#ware Engineering 19
} ContraindicaBon: Conflict with separaBon of concerns } Example: Who is responsible for saving a sale in the database? } Adding this responsibility to Sale would distribute database logic over many classes à low cohesion
} ContraindicaBon: Conflict with late binding } Late binding is available only for the receiver object } But maybe the variability of late binding is needed in some method argument instead
} Example: Support for mulBple serializaBon strategies
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Creator
21
Problem: Assign responsibility for creaBng a new instance of some class?
SoluBon: Determine which class should create instances of a class based on the relaBonship between potenBal creator classes and the class to be instanBated.
Creator
22
} who has responsibility to create an object? } By creator, assign class B responsibility of creaBng instance of class A if } B aggregates A objects } B contains A objects } B records instances of A objects } B closely uses A objects } B has the iniAalizing data for creaBng A objects
} where there is a choice, prefer } B aggregates or contains A objects
Creator : Example
23
Who is responsible for creaBng SalesLineItem objects? Look for a class that aggregates or contains SalesLineItem objects.
Sale
datetime
SalesLineItem
quantity
ProductSpecification
descriptionpriceUPC
Described-by
*
Contains
1..*
Creator : Example
24
Creator pa1ern suggests Sale. CollaboraBon diagram is
Creator
25
} Promotes low coupling by making instances of a class responsible for creaBng objects they need to reference
} By creaBng the objects themselves, they avoid being dependent on another class to create the object for them
Creator: Discussion
So#ware Engineering 26
} ContraindicaBons: } creaBon may require significant complexity, such as
} using recycled instances for performance reasons } condiBonally creaBng an instance from one of a family of similar classes based upon some external property value
} SomeBmes desired to outsource object wiring (“dependency injecBon”)
} Related pa1erns: } Abstract Factory, Singleton, Dependency InjecBon
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Low Coupling
28
Problem: How to support low dependency, low change impact, and increased reuse.
SoluBon: Assign a responsibility so that coupling remains low.
Why High Coupling is undesirable
So#ware Engineering 29
} Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.
} An element with low (or weak) coupling is not dependent on too many other elements (classes, subsystems, …) } "too many" is context-‐dependent
} A class with high (or strong) coupling relies on many other classes. } Changes in related classes force local changes. } Such classes are harder to understand in isolaBon. } They are harder to reuse because its use requires the addiBonal presence of the classes on which it is dependent.
Low Coupling
30
How can we make classes independent of other classes? changes are localised easier to understand easier to reuse Who has responsibility to create a payment and associate it to a sale?
Low Coupling
31
Two possibiliBes:
1. Register
2. Sale
Low coupling suggests Sale because Sale has to be coupled to Payment anyway (Sale knows its total).
Common Forms of Coupling in OO Languages
32
} TypeX has an a1ribute (data member or instance variable) that refers to a TypeY instance, or TypeY itself.
} TypeX has a method which references an instance of TypeY, or TypeY itself, by any means. } Typically include a parameter or local variable of type TypeY, or the
object returned from a message being an instance of TypeY.
} TypeX is a direct or indirect subclass of TypeY. } TypeY is an interface, and TypeX implements that interface.
Low Coupling: Discussion
So#ware Engineering 33
} Low Coupling is a principle to keep in mind during all design decisions
} It is an underlying goal to conBnually consider. } It is an evaluaAve principle that a designer applies while evaluaBng all design decisions.
} Low Coupling supports the design of classes that are more independent } reduces the impact of change.
} Can't be considered in isolaBon from other pa1erns such as Expert and High Cohesion
} Needs to be included as one of several design principles that influence a choice in assigning a responsibility.
Low Coupling: Discussion
So#ware Engineering 34
} Subclassing produces a parBcularly problemaBc form of high coupling } Dependence on implementaBon details of superclass } “Fragile Base Class Problem” [see SE Design Lecture]
} Extremely low coupling may lead to a poor design } Few incohesive, bloated classes do all the work; all other classes are just data containers
} ContraindicaBons: High coupling to very stable elements is usually not problemaBc
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
High Cohesion
36
Problem: How to keep complexity manageable.
SoluBon: Assign responsibiliBes so that cohesion remains high.
Cohesion is a measure of how strongly related and focused the responsibiliBes of an element are.
An element with highly related responsibiliBes, and which does not do a tremendous amount of work, has high cohesion
High cohesion
37
} Classes are easier to maintain } Easier to understand } O#en support low coupling } Supports reuse because of fine grained responsibility
High Cohesion
38
Who has responsibility to create a payment?
1.Register
looks OK if makePayement considered in isolaBon, but adding more system operaBons, Register would take on more and more responsibiliBes and become less cohesive.
High Cohesion
39
Giving responsibility to Sale supports higher cohesion in Register, as well as low coupling.
High Cohesion: Discussion
40
} Scenarios: } Very Low Cohesion: A Class is solely responsible for many things in very
different funcBonal areas } Low Cohesion: A class has sole responsibility for a complex task in one
funcBonal area. } High Cohesion. A class has moderate responsibiliBes in one funcBonal area
and collaborates with classes to fulfil tasks. } Advantages:
} Classes are easier to maintain } Easier to understand } O#en support low coupling } Supports reuse because of fine grained responsibility
} Rule of thumb: a class with high cohesion has a relaBvely small number of methods, with highly related funcBonality, and does not do too much work.
Problem: High Cohesion and Viewpoints
So#ware Engineering 41 [Harrison&Ossher ‘93]
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Controller
43
Problem: Who should be responsible for handling an input system event?
SoluBon: Assign the responsibility for receiving or handling a system event message to a class represenBng the overall system, device, or subsystem (facade controller) or a use case scenario within which the system event occurs (use case controller)
Controller: Example
So#ware Engineering 44
Controller: Example
So#ware Engineering 45
} By the Controller pa1ern, here are some choices: } Register, POSSystem: represents the overall "system," device, or subsystem
} ProcessSaleSession, ProcessSaleHandler: represents a receiver or handler of all system events of a use case scenario
Controller: Discussion
So#ware Engineering 46
} Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the acBvity. It does not do much work itself.
} Facade controllers are suitable when there are not "too many" system events
} A use case controller is an alternaBve to consider when placing the responsibiliBes in a facade controller leads to designs with low cohesion or high coupling } typically when the facade controller is becoming "bloated" with excessive responsibiliBes.
Controller: Discussion
So#ware Engineering 47
} Benefits } Increased potenBal for reuse, and pluggable interfaces
} No applicaBon logic in the GUI
} Dedicated place to place state that belongs to some use case } E.g. operaBons must be performed in a specific order
} Avoid bloated controllers! } E.g. single controller for the whole system, low cohesion, lots of state in controller
} Split into use case controllers, if applicable
} Interface layer does not handle system events
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Polymorphism
49
Problem: How to handle alternaBves based on types?
How to create pluggable so#ware components? SoluBon: When alternate behaviours are selected based on the type of an object, use polymorphic method call to select the behaviour, rather than using if/case statement to test the type.
Polymorphism: Example
So#ware Engineering 50
Polymorphism: Discussion
51
} Polymorphism is a fundamental principle in designing how a system is organized to handle similar variaBons.
} ProperBes: } Easier and more reliable than using explicit selecBon logic } Easier to add addiBonal behaviors later on } Increases the number classes in a design } May make the code less easy to follow
} Using the principle excessively for “future-‐proofing” against yet unknown potenBal future variaBons is a bad idea } Agile methods recommend to do no significant “upfront design” and add the variaBon point only when the need arises
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Pure FabricaBon
53
Problem: Adding some responsibiliBes to domain objects would violate high cohesion/low coupling/reuse
SoluBon: Assign a highly cohesive set of responsibiliBes to an arBficial or convenience class that does not represent a problem domain concept—something made up, to support high cohesion, low coupling, and reuse.
Pure FabricaBon: Example
54
} In the point of sale example support is needed to save Sale instances in a relaBonal database.
} By Expert, there is some jusBficaBon to assign this responsibility to Sale class.
} However, the task requires a relaBvely large number of supporBng database-‐oriented operaBons and the Sale class becomes incohesive.
} The sale class has to be coupled to the relaBonal database increasing its coupling.
} Saving objects in a relaBonal database is a very general task for which many classes need support. Placing these responsibiliBes in the Sale class suggests there is going to be poor reuse or lots of duplicaBon in other classes that do the same thing.
Pure FabricaBon : Example
55
} SoluBon: create a new class that is solely responsible for saving objects in a persistent storage medium
} This class is a Pure FabricaBon
} The Sale remains well-‐designed, with high cohesion and low coupling
} The PersistentStorageBroker class is itself relaBvely cohesive } The PersistentStorageBroker class is a very generic and reusable
object
Pure FabricaBon: Discussion
56
} The design of objects can be broadly divided into two groups: } Those chosen by representaBonal decomposiBon (e.g. Sale) } Those chosen by behavioral decomposiBon (e.g. an algorithm object such as TOCGenerator or PersistentStorage)
} Both choices are valid designs, although the second one corresponds less well to the modeling perspecBve on objects
} If overused, it can lead to a non-‐idiomaBc design, namely a separaBon of the code into data and behavior as in procedural programming } Coupling of data and behavior is central to OO design
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
IndirecBon
58
Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-‐couple objects so that low coupling is supported and reuse potenBal remains higher?
SoluBon: Assign the responsibility to an intermediate object to mediate between other components or services, so that they are not directly coupled.
"Most problems in computer science can be solved
by another level of indirecBon"
IndirecBon: Example
So#ware Engineering 59
By adding a level of indirecBon and adding polymorphism, the adapter objects protect the inner design against variaBons in the external interfaces
Nine GRASP pa1erns: } InformaBon Expert } Creator } Low Coupling } Controller } High Cohesion } Polymorphism } IndirecBon } Pure FabricaBon } Protected VariaBons
Protected VariaBon
So#ware Engineering 61
Problem: How to design objects, subsystems, and systems so that the variaBons or instability in these elements does not have an undesirable impact on other elements? SoluBon: IdenBfy points of predicted variaBon or instability; assign responsibiliBes to create a stable interface around them. Note: This is basically just another formulaAon of the informaAon hiding principle.
Protected VariaBon: Examples
So#ware Engineering 62
} Data encapsulaBon, interfaces, polymorphism, indirecBon, and standards are moBvated by PV.
} Virtual machines are complex examples of indirecBon to achieve PV
} Service lookup: Clients are protected from variaBons in the locaBon of services, using the stable interface of the lookup service.
} Uniform Access Principle } Law of Demeter } …
Literature
So#ware Engineering 63
} Craig Larman, Applying UML and Pa1erns, PrenBce Hall, 2004 } Chapter 16+17+22 introduce GRASP
