COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647- w2006.html
Feb 13, 2016
COMP 6471Software Design Methodologies
Winter 2006Dr Greg Butler
http://www.cs.concordia.ca/~gregb/home/comp647-w2006.html
The 9 GRASP Principles1. Expert2. Creator3. Controller4. Low Coupling5. High Cohesion6. Polymorphism7. Pure Fabrication8. Indirection9. Protected Variations
Principle: Information Expert
Assign a responsibility to the object that has the information necessary to fulfill it.“That which has the information, does the
work.”
Eg, Which object knows whether a user has permission to access a given document?
Principle: Creator
What object creates an X?Choose an object C, such that:
– C contains or aggregates X– C closely uses X– C has the initializing data for X
The more, the better.
Eg, Which object creates a session, user, project, document?
Principle: Creator
What object creates a Command?
Principle: ControllerWhat object in the domain (or application
coordination layer) receives requests for work from the UI layer?
Solution: Choose a class whose name suggests:– The overall “system”, device, or subsystem
• A kind of Façade class– Or, represents the use case scenario or
session
Principle: Controller
Eg, What object receives a request to logon and begin a session?
Eg, What object receives the request to perform a command?
Guideline: Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It does not do much work itself.
Principle: PolymorphismHow to handle alternatives based on type …How to create pluggable software components …Assign responsibility for the behaviour to a polymorphic
operation in the superclass-subclass hierarchy.
Clearly generalization and polymorphism handles the situation where behaviour varies by type.
To create pluggable components adopt a client-server relationship, then vary server using polymorphism: each server subclass is a pluggable component.
Principle: PolymorphismImplies that your code should never have switch’s or
conditional logic that tests the type of an object!
Eg, in CUWME where is polymorphism used?Command classComposite pattern: Document classRole: is using RBAC1…
Principle: Pure FabricationWhen assigning responsibilities to an existing object would
violate cohesion or coupling or …Assign a highly cohesive set of responsibilities to an
artificial (or convenience) class that does not represent a problem domain concept – something made up to support high cohesion, low coupling, and reuse.
Pure – because it is a clean design (high cohesion, low coupling)
Fabrication – because it is made up, invented, imagined
Principle: Pure FabricationEg, controller objects are pure fabricationSo the Controller Principle is a special case of Pure
Fabrication Principle
Eg, PersistentStorage class is an example of Pure Fabrication
Principle: Pure FabricationDesign of objects can be divided into two groups:• Representational decomposition
Ie those related to representation of entities and their components, such as Sale, Vehicle, Document, …
While these generally are in the problem domain, sometimes we have design representations that group them: eg DOM tree of a document is pure fabrication
• Behavioural decompositionIe those related to representation of a process or algorithm. This
includes controller classes for use cases, Command class, Strategy class, etc
These are generally not in the problem domain model, and are mostly pure fabrication.
Principle: IndirectionHow to avoid direct coupling …How to de-couple objects …Assign the responsibility to an intermediate object to
mediate between other components or services so that they are not directly coupled.
Eg, Adaptor class to de-couple dependency on an explicit third-party interface.
Eg, Façade classes to de-couple external objects from objects internal to the component.
Eg, uses in CUWME?
Principle: Indirection
“Most problems in computer science can be solved by adding another layer of indirection.” [David Wheeler]
“Most problems in performance can be solved by removing another layer of indirection!”
Principle: Protected VariationsHow to design objects so that variations or instability in
these elements does not have an undesirable impact on other elements?
Identify points of predicted variation or instability; Assign responsibilities to create a stable interface around them.
Eg, information hidingEg, Polymorphism Principle: Allowing pluggable
components using polymorphism of servers in a client-server relationship
Cf, anticipated changes
Principle: Protected VariationsCore mechanisms for Protected Variations• Data encapsulation• Interfaces• Polymorphism• Indirection• Standards (eg APIs like JDBC)Note that these include virtual machines hiding OS, DB,
network, etc
Principle: Protected VariationsOther mechanisms for Protected Variations
• Data-driven designs• Callback (eg Observer, Listener), service lookup• Interpreter-driven designs
• Reflection or meta-level designs
• Structure hiding designs, such as composite pattern with iterator and visitor pattern for accessing and traversing the structure
Principle: Protected VariationsTwo kinds of change:
• Variation pointVariations in the existing current system or requirements that must
be supported in this system.
• Evolution pointSpeculative points of variation that may arise in the future, but
which are not present in the existing requirements.
Principle: Protected VariationsExamples in CUWME?
Principle: Low CouplingAssign responsibilities so that coupling remains low.
Definition: Coupling is a measure of how strongly one element – is connected to, – has knowledge of, or – relies on
other elements.
An element with low coupling is not dependent on too many other elements.
“too many” is context-dependent
Principle: Low CouplingLow coupling is an evaluative principle that can
always be applied to evaluate alternative designs.
Principle: Low CouplingForms of coupling:• TypeX has an attribute that refers to a TypeY
instance• A TypeX object calls on services of a TypeY
object• TypeX has a method that references an instance
of TypeY, or TypeY itself (ie as parameter, local variable, or return object)
• TypeX is a direct or indirect subclass of TypeY• TypeY is an interface, and TypeX implements
that interface.
Principle: High CohesionAssign responsibilities so that cohesion remains
high.
Definition: (Functional) cohesion is a measure of how strongly related and focused the responsibilities of an element are.
High cohesion is an evaluative principle that can always be applied to evaluate alternative designs.
Principle: Modularity = Low Coupling + High Cohesion
“Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” [Booch 1994]