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]