COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler

The 9 GRASP Principles 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion 6.Polymorphism 7.Pure Fabrication 8.Indirection 9.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: Controller What 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: Polymorphism How 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: Polymorphism Implies 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 class Composite pattern: Document class Role: is using RBAC1 …

Principle: Pure Fabrication When 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 Fabrication Eg, controller objects are pure fabrication So the Controller Principle is a special case of Pure Fabrication Principle Eg, PersistentStorage class is an example of Pure Fabrication

Principle: Pure Fabrication Design 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 decomposition Ie 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: Indirection How 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 Variations How 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 hiding Eg, Polymorphism Principle: Allowing pluggable components using polymorphism of servers in a client- server relationship Cf, anticipated changes

Principle: Protected Variations Core 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 Variations Other 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 Variations Two kinds of change: Variation point Variations in the existing current system or requirements that must be supported in this system. Evolution point Speculative points of variation that may arise in the future, but which are not present in the existing requirements.

Principle: Protected Variations Examples in CUWME?

Principle: Low Coupling Assign 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 Coupling Low coupling is an evaluative principle that can always be applied to evaluate alternative designs.

Principle: Low Coupling Forms 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 Cohesion Assign 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]