240 likes | 250 Views
COMP 6471 Software Design Methodologies. Winter 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-w2006.html. The 9 GRASP Principles. Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication Indirection Protected Variations.
E N D
COMP 6471Software Design Methodologies Winter 2006 Dr Greg Butler http://www.cs.concordia.ca/~gregb/home/comp647-w2006.html
The 9 GRASP Principles • Expert • Creator • Controller • Low Coupling • High Cohesion • Polymorphism • Pure Fabrication • Indirection • 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]