SlideShare uma empresa Scribd logo
1 de 58
Baixar para ler offline
Harsh Jegadeesan’s CLASSROOM




GRASP: DESIGNING OBJECTS
WITH RESPONSIBILITIES




                               BITS Pilani
                               Off-Campus Work-Integrated Learning Programmes
USE-CASE REALIZATION
 How a particular use-case is realized in the
 design model in terms of collaborating objects?

 Use-Case suggests system operations

 Domain-Layer interaction diagrams illustrate
 use-case realization




                                                   2
GRASP : DESIGN OBJECTS WITH
RESPONSIBILITIES
GRASP patterns are a learning aid to help one
understand essential object design, and apply
design reasoning in a methodical,
rational,explainable way.




                                                3
DESIGN ACTIVITIES
 During design and coding we apply various OO
 design principles, among them software design
 patterns such as the GRASP and GoF (Gang of
 Four) patterns.

 Our metaphor is Responsibility Driven Design
 (RDD), because our chief design emphasis is on
 assigning responsibilities to objects.



                                                  4
RESPONSIBILITIES AND METHODS
  Responsibilities are realized as methods
  Approach to understanding and using design
  principles is based on patterns of assigning
  responsibilities.
  Definition of Responsibility:
  “A contract or obligation of a classifier”
   Responsibilities are of the following types:
    Knowing
    Doing
                                                  5
DOING


Doing responsibilities of an object include :
  Doing something itself , such as creating an object or
  doing a calculation
  Initialing action in other objects
  Controlling and coordinating activities in other objects




                                                             6
KNOWING
Knowing responsibilities of object include :
  Knowing about private encapsulated data
  Knowing about related objects
  Knowing about things it can derive or calculate




                                                    7
RESPONSIBILITIES AND INTERACTION DIAGRAMS

Interaction diagrams show choices in assigning
responsibilities to objects.

When these diagrams are created, decisions in
responsibility assignment are reflected in the
messages sent to different classes of objects.




                                                 8
PATTERNS
 Principles and idioms codified in a structured
 format describing the problem, solution, and
 given a name are called patterns.

 A “New Pattern” is an oxymoron. Patterns are
 tried and true, established ways of doing things.
 They are not new things or new ways of doing
 things.



                                                     9
DEFINITION OF PATTERN
Pattern is a named problem/solution pair that
can be applied in new contexts,with advice on
how to apply it in novel situations and discussion
of its trade-offs.




                                                     10
NAMING PATTERNS
All Patterns have suggestive names. Naming a
pattern, technique, or a principle has the
following advantages :

  It supports chunking and incorporating that concept
  into our understanding and memory
  It facilitates communication .




                                                        11
CHANGING EMPHASIS
    Throughout analysis, we have referred to
    analyzing the problem domain, and postponing
    consideration of the solution domain. We
    emphasized domain objects over software objects
.
    That changes in design. We are now concerned
    with software objects and the solution domain.




                                                      12
GRASP
The GRASP name was chosen to suggest the
importance of grasping these principles to successfully
design object-oriented software.

It is an acronym for General Responsibility Assignment
Software Patterns.

They describe the fundamental principles of object
design and responsibility assignment, expressed as
patterns.


                                                          13
FIVE BASIC GRASP PATTERNS :

  Information Expert
  Creator
  High Cohesion
  Low Coupling
  Controller




                              14
UML CLASS DIAGRAM NOTATION
 Three sections:



   Class Name
                   Third section is for methods

   attributes

   methods



                                                  15
CREATOR

Problem: Who should be responsible for creating a
new instance of some class ?
The creation of objects is one of the most common
activities in an object-oriented system.
It is useful to have a general principle for
assignment of creation responsibilities.
 Assigned well, the design can support low coupling
increased clarity, encapsulation, and reusability.


                                                      16
MONOPOLY CONCEPTS (CANDIDATES)

Monopoly Game   Player    Piece




Die              Board   Square




                                   17
SOLUTION
 Assign class B the responsibility to create an
 instance of class A if one or more of the following
 is true :
   B aggregates A objects .
   B contains A objects.
   B records instances of A objects.
   B closely uses A objects.
   B has the initializing data that will be passed to A
   when it is created
   B is a creator of A objects.

                                                          18
DISCUSSION
The basic intent of the Creator pattern is to find a
creator that needs to be connected to the created object
in any event.

  Aggregator aggregates Part
  Container contains Content
  Recorder records.

Sometimes a creator is found by looking for the class
that has the initializing data that will be passed in
during creation.

                                                        19
CONTRAINDICATIONS
 Often creation requires significant complexity,
 such as:
   using recycled instances for performance reasons,
   conditionally creating an instance from one of a
   family of similar classes based upon some external
   property value


 In these instances, another pattern principle
 might be preferred (factory?)


                                                        20
MONOPOLY EXAMPLE
 In the monopoly example, who will create the
 Squares?

 Since the game board contains the squares where
 activities take place, a Board software object is a
 logical place to create Square software objects.




                                                       21
INFORMATION EXPERT

By Information expert we should look for the class of
objects that has all the information needed

Problem : What is a general principle of assigning
responsibilities to objects?

Solution: Assign a responsibility to the information
expert – a class that has the information necessary to
fulfill the responsibility.
                                                         22
DISCUSSION
Information Expert is a basic guiding principle used
continuously in object design.

Expert is not meant to be obscure or fancy idea; it
expresses the common “intuition” that objects do
things related to information they have.

Fulfillment of a responsibility often requires
information that is spread across different classes of
objects.

Whenever information is spread across different
objects , they will need to interact via messages to     23
share the work.
CONTRAINDICATIONS
 There are situations where the solution
 suggested by expert is undesirable, usually
 because of problems in coupling and cohesion.

 Keep the application logic in one place, database
 in another place and so forth, rather than
 intermingling different system concerns in the
 same component.



                                                     24
BENEFITS

Information encapsulation is maintained, since objects
use their own information to fulfill tasks. This usually
supports low coupling, which leads to more robust and
maintainable systems.

Behavior is distributed across the classes that have the
required information, encouraging more cohesive
“lightweight” class definitions that are easier to
understand and maintain.

High cohesion is usually supported.
                                                       25
MONOPOLY EXAMPLE
 If you want to retrieve information about the
 squares on the board, who does it?

 The Board software object is also a good choice,
 as it was for creating the Square objects.

 Note that the information is retrieved from the
 Squares.



                                                    26
LOW COUPLING
  Coupling is a measure of how strongly one
  element is connected to, has knowledge of, or
  relies on other element.




                                                  27
LOW COUPLING PATTERN
 Problem:
 How to support a low dependency, low change
 impact ,and increased reuse?

 Solution:
 Assign a responsibility so that coupling remains
 low.




                                                    28
DISCUSSION
 Low Coupling is a principle to keep in mind
 during all design decisions

 It is an underlying goal to continually consider. It
 is evaluative principle that a designer applies
 while evaluating all design decisions.




                                                        29
CONTRAINDICATIONS & BENEFITS
 (High coupling to stable elements and to
 pervasive elements is seldom a problem.)
 Benefits:
 Objects are not affected by changes in other
 components
 Objects are simple to understand in isolation
 Objects are convenient to reuse




                                                 30
MONOPOLY EXAMPLE
 If we created an arbitrary other class to retrieve
 information from the Squares instead of
 assigning the responsibility to the Board object,
 then our other class would have to retrieve
 information from both Board and Square,
 increasing the number of connections (and thus
 the coupling.)




                                                      31
CONNECTIONS BETWEEN PATTERNS
Information Expert supports Low Coupling.

 This is a natural result of identifying patterns
from practices that have developed over years of
experience.

You often get the same result by starting with a
different idea, because the ideas (patterns)
support each other.

                                                    32
HIGH COHESION
 Cohesion is a measure of how strongly related
 and focused are the responsibilities of an
 element.
 High Cohesion: An element with highly related
 responsibilities, and which does not do a
 tremendous amount of work, has high cohesion.




                                                 33
HIGH COHESION PATTERN


Problem:
How can complexity be kept manageable?
Solution:
Assign responsibility so that cohesion remains high.




                                                       34
DISCUSSION
 Like Low Coupling, High Cohesion is a principle
 to keep in mind during all design decisions; it is
 an underlying goal to consider contantly.




                                                      35
MONOPOLY EXAMPLE
 Assuming, from the previous Monopoly slide,
 that :MonopolyGame is the controller:
 If :MonopolyGame performs most of the game
 functions within the software object, you have
 low cohesion.
 If the functions are delegated to other software
 objects, you have high cohesion.




                                                    36
BACK TO RELATIONSHIPS
 Low Coupling and High Cohesion go together
 naturally. One usually leads to the other.
 Both are outcomes of the OO principle of
 “chunking,” breaking up a large problem into
 manageable pieces.
 If the pieces are too simple there will be too many
 of them.
 If the pieces are too complex, each will not be
 understandable.


                                                       37
COHESION EXAMPLES

Some scenarios illustrating varying degrees of varying
degrees of functional cohesion:
Very Low Cohesion – A class is solely responsible for
many different functional areas.
Low Cohesion – A class has sole responsibility for a
complex task in one functional area.




                                                         38
Moderate Cohesion – A class has light weight
and sole responsibilities in a few different areas
that are logically related to the class concept, but
not to each other.
High Cohesion – A class has moderate
responsibilities in one functional area and
collaborates with other classes to fulfill tasks.




                                                       39
CONTRAINDICATIONS

Grouping of responsibilities or code into one class or
component to simplify maintenance by one person.
(Such grouping may also make maintenance much
more difficult.)
Distributed server objects.
It is sometimes desirable to create fewer and larger,
less cohesive server objects that provide an interface
for many operations, due to overhead and performance
needs associated with remote objects and remote
communication.

                                                         40
BENEFITS
 Clarity and ease of comprehension of design is
 increased.
 Maintenance and enhancements are simplified
 Low coupling is often supported.




                                                  41
CONTROLLER

 A Controller is a non–user interface object responsible
 for receiving or handling a system event. It defines
 methods for system operation.




                                                      42
PROBLEM :
 Who should be responsible for handling an input
 system event?
 Note that this assumes the Model-View-
 Controller architectural (not software) pattern
 that separates the user interface (Views) from
 the functionality of the rest of the system and
 uses controllers to access other functionality
 (Models).



                                                   43
SOLUTION
 Assign the responsibility for receiving or
 handling a system event message to a class
 representing one of the following choices:
   Represent the overall system, device, or
   subsystem
   Represents a use case scenario within
   which the system event occurs



                                              44
DISCUSSION
 Controller pattern provides guidance for
 generally accepted, suitable choices.
 It is often desirable to use the same controller
 class for all the system events of one use case so
 that it is possible to maintain information about
 the state of the use case in the controller.




                                                      45
MONOPOLY EXAMPLE
 The first system message is “Play Game.” What
 object should receive this message?
 The author suggests that :MonopolyGame might
 be a suitable object if there are a limited number
 of system operations. Otherwise, we would have
 to consider High Cohesion if there are many
 operations.




                                                      46
FACADE CONTROLLER
 Suitable when there are not “too many” system
 events ,or it is not possible for the user interface
 (UI) to redirect system event messages to
 alternating controllers,such as in message
 processing system.




                                                        47
USE–CASE CONTROLLER
 When placing the responsibilities in a façade
 controller leads to design with low cohesion or
 high coupling, Use Case Controller is preferred
 as an alternative.

 When there are many system events across
 different processes, it factors their handling into
 manageable separate classes.



                                                       48
AN OBJECT CLASSIFICATION SCHEMA

The following analysis class types are used by Ivar
Jacobsen in Objectory:
  Boundary objects are abstractions of interfaces
  Entity objects are application-independent domain software
  objects
  Control objects are use case handlers
Jacobsen was a contributor to UML, and the controller
pattern reflects his approach.


                                                          49
VISIBILITY
 Visibility is the ability of one object to “see” or have
 reference to another object

 Visibility is required for one object to message
 another

 Attribute visibility: Y is an attribute of Class X

 Parameter visibility: Y is parameter of Method X

 Local Visibility: Y is a local object in a method of
 Class X

 Global Visibility: Y is globally dependent                 50
OTHER GRASP PATTERNS
 Polymorphism
 Pure Fabrication
 Indirection
 Protected Variation




                       51
POLYMORPHISM
 Problem: How to handle alternatives based on
 types? (conditional themes) How to design
 pluggable software components?

 Solution: when the related alternatives or
 behaviors vary by type, assign responsibilities for
 the behavior using polymorphic operations




                                                       52
BENEFITS
 Extensions required for new variations are easy
 to add

 New implementation can be introduced without
 affecting clients




                                                   53
PURE FABRICATION
 Problem: What object should have the
 responsibility, when you do not want to violate
 High Cohesion and Low Coupling, or other goals,
 but solutions offered by Expert are not
 appropriate?

 Assigning responsibilities to only domain layer
 software classes leads to problems in terms of
 poor cohesion or coupling – low reuse!


                                                   54
PURE FABRICATION (2)
 Solution: Assign a highly cohesive set of
 responsibilities to an artificial or convenience
 class that does not represent a problem domain
 concept
 Design of objects is divided into:
   Representational decomposition
   Behavioral decomposition


 Benefits:
   High-Cohesion
   Reuse potential
                                                    55
INDIRECTION
 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 potential
 remains high?

 Solution: Assign the responsibility to an
 intermediary object to mediate between other
 components or services so that they are not
 directly coupled.

                                                56
PROTECTED VARIATIONS
 Problem: How to design objects, subsystems so
 that the variations or instability in these
 elements does not have an undesirable impact on
 other elements?

 Solution: Identify points of predicated variation
 or instability, assign responsibility to create a
 stable interface around them.



                                                     57
SUMMARY
The skillful assignment of responsibilities is
extremely important in object design.
Determining the assignment of responsibilities
often occurs during the creation of interaction
diagrams , and certainly during programming.
Patterns are named problem/solution pairs that
codify good advice and principles often related to
assignment of responsibilities.



                                                     58

Mais conteúdo relacionado

Mais procurados

McCall Software Quality Model in Software Quality Assurance
McCall Software Quality Model in Software Quality Assurance McCall Software Quality Model in Software Quality Assurance
McCall Software Quality Model in Software Quality Assurance sundas Shabbir
 
Compiler Design Lecture Notes
Compiler Design Lecture NotesCompiler Design Lecture Notes
Compiler Design Lecture NotesFellowBuddy.com
 
OS - Process Concepts
OS - Process ConceptsOS - Process Concepts
OS - Process ConceptsMukesh Chinta
 
Object-Oriented Analysis and Design
Object-Oriented Analysis and DesignObject-Oriented Analysis and Design
Object-Oriented Analysis and DesignRiazAhmad786
 
Basics of Object Oriented Programming
Basics of Object Oriented ProgrammingBasics of Object Oriented Programming
Basics of Object Oriented ProgrammingAbhilash Nair
 
Java. Инкапсуляция.
Java. Инкапсуляция.Java. Инкапсуляция.
Java. Инкапсуляция.Unguryan Vitaliy
 
Storage organization and stack allocation of space
Storage organization and stack allocation of spaceStorage organization and stack allocation of space
Storage organization and stack allocation of spaceMuhammad Haroon
 
System call (Fork +Exec)
System call (Fork +Exec)System call (Fork +Exec)
System call (Fork +Exec)Amit Ghosh
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)IIUI
 
Interrupt handling
Interrupt handlingInterrupt handling
Interrupt handlingmaverick2203
 
Functional programming
Functional programmingFunctional programming
Functional programmingijcd
 
Beneath the Linux Interrupt handling
Beneath the Linux Interrupt handlingBeneath the Linux Interrupt handling
Beneath the Linux Interrupt handlingBhoomil Chavda
 
Software engineering principles in system software design
Software engineering principles in system software designSoftware engineering principles in system software design
Software engineering principles in system software designTech_MX
 
Superscalar & superpipeline processor
Superscalar & superpipeline processorSuperscalar & superpipeline processor
Superscalar & superpipeline processorMuhammad Ishaq
 
Method overloading, recursion, passing and returning objects from method, new...
Method overloading, recursion, passing and returning objects from method, new...Method overloading, recursion, passing and returning objects from method, new...
Method overloading, recursion, passing and returning objects from method, new...JAINAM KAPADIYA
 
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014Davidlohr Bueso
 
System Sequence Diagrams.pdf
System Sequence Diagrams.pdfSystem Sequence Diagrams.pdf
System Sequence Diagrams.pdfLinuLalachan
 

Mais procurados (20)

McCall Software Quality Model in Software Quality Assurance
McCall Software Quality Model in Software Quality Assurance McCall Software Quality Model in Software Quality Assurance
McCall Software Quality Model in Software Quality Assurance
 
Compiler Design Lecture Notes
Compiler Design Lecture NotesCompiler Design Lecture Notes
Compiler Design Lecture Notes
 
OS - Process Concepts
OS - Process ConceptsOS - Process Concepts
OS - Process Concepts
 
Object-Oriented Analysis and Design
Object-Oriented Analysis and DesignObject-Oriented Analysis and Design
Object-Oriented Analysis and Design
 
Phases of Compiler
Phases of CompilerPhases of Compiler
Phases of Compiler
 
Basics of Object Oriented Programming
Basics of Object Oriented ProgrammingBasics of Object Oriented Programming
Basics of Object Oriented Programming
 
Java. Инкапсуляция.
Java. Инкапсуляция.Java. Инкапсуляция.
Java. Инкапсуляция.
 
Storage organization and stack allocation of space
Storage organization and stack allocation of spaceStorage organization and stack allocation of space
Storage organization and stack allocation of space
 
System call (Fork +Exec)
System call (Fork +Exec)System call (Fork +Exec)
System call (Fork +Exec)
 
Lecture 12 requirements modeling - (system analysis)
Lecture 12   requirements modeling - (system analysis)Lecture 12   requirements modeling - (system analysis)
Lecture 12 requirements modeling - (system analysis)
 
Interrupt handling
Interrupt handlingInterrupt handling
Interrupt handling
 
Functional programming
Functional programmingFunctional programming
Functional programming
 
Beneath the Linux Interrupt handling
Beneath the Linux Interrupt handlingBeneath the Linux Interrupt handling
Beneath the Linux Interrupt handling
 
Software engineering principles in system software design
Software engineering principles in system software designSoftware engineering principles in system software design
Software engineering principles in system software design
 
Superscalar & superpipeline processor
Superscalar & superpipeline processorSuperscalar & superpipeline processor
Superscalar & superpipeline processor
 
Debugging
DebuggingDebugging
Debugging
 
Method overloading, recursion, passing and returning objects from method, new...
Method overloading, recursion, passing and returning objects from method, new...Method overloading, recursion, passing and returning objects from method, new...
Method overloading, recursion, passing and returning objects from method, new...
 
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014
An Overview of [Linux] Kernel Lock Improvements -- Linuxcon NA 2014
 
Introduction to UML
Introduction to UMLIntroduction to UML
Introduction to UML
 
System Sequence Diagrams.pdf
System Sequence Diagrams.pdfSystem Sequence Diagrams.pdf
System Sequence Diagrams.pdf
 

Destaque

SOA India 2009 | SOA and Web Business Platforms
SOA India 2009 | SOA and Web Business PlatformsSOA India 2009 | SOA and Web Business Platforms
SOA India 2009 | SOA and Web Business PlatformsHarsh Jegadeesan
 
Web Business Platforms On The Cloud An Engineering Perspective
Web Business Platforms On The Cloud   An Engineering PerspectiveWeb Business Platforms On The Cloud   An Engineering Perspective
Web Business Platforms On The Cloud An Engineering PerspectiveHarsh Jegadeesan
 
APIs make you mobile - Mobile World Congress 2017
APIs make you mobile - Mobile World Congress 2017APIs make you mobile - Mobile World Congress 2017
APIs make you mobile - Mobile World Congress 2017Harsh Jegadeesan
 
Writing Effective Use Cases
 Writing Effective Use Cases Writing Effective Use Cases
Writing Effective Use CasesHarsh Jegadeesan
 
Intelligent Business Operations for Utilities, powered by SAP HANA
Intelligent Business Operations for Utilities, powered by SAP HANAIntelligent Business Operations for Utilities, powered by SAP HANA
Intelligent Business Operations for Utilities, powered by SAP HANAHarsh Jegadeesan
 
SAP API Business Hub - SAP Community Webinar
SAP API Business Hub - SAP Community Webinar SAP API Business Hub - SAP Community Webinar
SAP API Business Hub - SAP Community Webinar Harsh Jegadeesan
 
SAP TechEd 2015 INT103 Enabling Digital Transformation with APIs and SAP API...
SAP TechEd  2015 INT103 Enabling Digital Transformation with APIs and SAP API...SAP TechEd  2015 INT103 Enabling Digital Transformation with APIs and SAP API...
SAP TechEd 2015 INT103 Enabling Digital Transformation with APIs and SAP API...Harsh Jegadeesan
 
Apply Design Thinking to enable Digital Business Transformation with SAP In...
Apply Design Thinking to enable Digital Business Transformation with SAP In...Apply Design Thinking to enable Digital Business Transformation with SAP In...
Apply Design Thinking to enable Digital Business Transformation with SAP In...Harsh Jegadeesan
 
Plan idei start up start up your idea
Plan idei start up start up your ideaPlan idei start up start up your idea
Plan idei start up start up your ideaGRASP
 
780 吴冠中画 3(Hys 2009)
780 吴冠中画 3(Hys 2009)780 吴冠中画 3(Hys 2009)
780 吴冠中画 3(Hys 2009)yangbqada
 
大山里的人(二)
大山里的人(二)大山里的人(二)
大山里的人(二)yangbqada
 

Destaque (20)

SOA India 2009 | SOA and Web Business Platforms
SOA India 2009 | SOA and Web Business PlatformsSOA India 2009 | SOA and Web Business Platforms
SOA India 2009 | SOA and Web Business Platforms
 
Web Business Platforms On The Cloud An Engineering Perspective
Web Business Platforms On The Cloud   An Engineering PerspectiveWeb Business Platforms On The Cloud   An Engineering Perspective
Web Business Platforms On The Cloud An Engineering Perspective
 
APIs make you mobile - Mobile World Congress 2017
APIs make you mobile - Mobile World Congress 2017APIs make you mobile - Mobile World Congress 2017
APIs make you mobile - Mobile World Congress 2017
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Writing Effective Use Cases
 Writing Effective Use Cases Writing Effective Use Cases
Writing Effective Use Cases
 
Domain Modeling
Domain ModelingDomain Modeling
Domain Modeling
 
Modeling Software
Modeling SoftwareModeling Software
Modeling Software
 
Case Study Guidelines
Case Study GuidelinesCase Study Guidelines
Case Study Guidelines
 
Intelligent Business Operations for Utilities, powered by SAP HANA
Intelligent Business Operations for Utilities, powered by SAP HANAIntelligent Business Operations for Utilities, powered by SAP HANA
Intelligent Business Operations for Utilities, powered by SAP HANA
 
SAP API Business Hub - SAP Community Webinar
SAP API Business Hub - SAP Community Webinar SAP API Business Hub - SAP Community Webinar
SAP API Business Hub - SAP Community Webinar
 
SAP TechEd 2015 INT103 Enabling Digital Transformation with APIs and SAP API...
SAP TechEd  2015 INT103 Enabling Digital Transformation with APIs and SAP API...SAP TechEd  2015 INT103 Enabling Digital Transformation with APIs and SAP API...
SAP TechEd 2015 INT103 Enabling Digital Transformation with APIs and SAP API...
 
SAP API Business Hub
SAP API Business HubSAP API Business Hub
SAP API Business Hub
 
Apply Design Thinking to enable Digital Business Transformation with SAP In...
Apply Design Thinking to enable Digital Business Transformation with SAP In...Apply Design Thinking to enable Digital Business Transformation with SAP In...
Apply Design Thinking to enable Digital Business Transformation with SAP In...
 
Plan idei start up start up your idea
Plan idei start up start up your ideaPlan idei start up start up your idea
Plan idei start up start up your idea
 
User guide
User guideUser guide
User guide
 
Html 5 tags
Html  5 tagsHtml  5 tags
Html 5 tags
 
Domain model
Domain modelDomain model
Domain model
 
780 吴冠中画 3(Hys 2009)
780 吴冠中画 3(Hys 2009)780 吴冠中画 3(Hys 2009)
780 吴冠中画 3(Hys 2009)
 
No sql exploration keyvaluestore
No sql exploration   keyvaluestoreNo sql exploration   keyvaluestore
No sql exploration keyvaluestore
 
大山里的人(二)
大山里的人(二)大山里的人(二)
大山里的人(二)
 

Semelhante a Responsibility Driven Design

CS8592 Object Oriented Analysis & Design - UNIT IV
CS8592 Object Oriented Analysis & Design - UNIT IV CS8592 Object Oriented Analysis & Design - UNIT IV
CS8592 Object Oriented Analysis & Design - UNIT IV pkaviya
 
Object-Oriented Design Heuristics
Object-Oriented Design HeuristicsObject-Oriented Design Heuristics
Object-Oriented Design Heuristicskim.mens
 
Introduction to Design Pattern
Introduction to Design  PatternIntroduction to Design  Pattern
Introduction to Design PatternSanae BEKKAR
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patternsAmit Kabra
 
Design in construction
Design in constructionDesign in construction
Design in constructionAsha Sari
 
Design in construction
Design in constructionDesign in construction
Design in constructionAsha Sari
 
SE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design PatternsSE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design PatternsAmr E. Mohamed
 
Patterns of Assigning Responsibilities
Patterns of Assigning ResponsibilitiesPatterns of Assigning Responsibilities
Patterns of Assigning Responsibilitiesguest2a92cd9
 
SE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design PatternsSE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design PatternsAmr E. Mohamed
 
A laboratory for teaching object oriented thinking
A laboratory for teaching object oriented thinkingA laboratory for teaching object oriented thinking
A laboratory for teaching object oriented thinkingHome
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software EngineeringVarsha Ajith
 
1. oop with c++ get 410 day 1
1. oop with c++ get 410   day 11. oop with c++ get 410   day 1
1. oop with c++ get 410 day 1Mukul kumar Neal
 
CSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsCSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsbutest
 
CSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsCSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsbutest
 

Semelhante a Responsibility Driven Design (20)

CS8592 Object Oriented Analysis & Design - UNIT IV
CS8592 Object Oriented Analysis & Design - UNIT IV CS8592 Object Oriented Analysis & Design - UNIT IV
CS8592 Object Oriented Analysis & Design - UNIT IV
 
Object-Oriented Design Heuristics
Object-Oriented Design HeuristicsObject-Oriented Design Heuristics
Object-Oriented Design Heuristics
 
Introduction to Design Pattern
Introduction to Design  PatternIntroduction to Design  Pattern
Introduction to Design Pattern
 
CS8592-OOAD Lecture Notes Unit-4
CS8592-OOAD Lecture Notes Unit-4CS8592-OOAD Lecture Notes Unit-4
CS8592-OOAD Lecture Notes Unit-4
 
Introduction to design patterns
Introduction to design patternsIntroduction to design patterns
Introduction to design patterns
 
PMSE pdf
PMSE pdfPMSE pdf
PMSE pdf
 
Birasa 1
Birasa 1Birasa 1
Birasa 1
 
JAVA PROGRAMMING
JAVA PROGRAMMING JAVA PROGRAMMING
JAVA PROGRAMMING
 
JAVA PROGRAMMINGD
JAVA PROGRAMMINGDJAVA PROGRAMMINGD
JAVA PROGRAMMINGD
 
Design in construction
Design in constructionDesign in construction
Design in construction
 
Design in construction
Design in constructionDesign in construction
Design in construction
 
SE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design PatternsSE2_Lec 19_Design Principles and Design Patterns
SE2_Lec 19_Design Principles and Design Patterns
 
Patterns of Assigning Responsibilities
Patterns of Assigning ResponsibilitiesPatterns of Assigning Responsibilities
Patterns of Assigning Responsibilities
 
SE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design PatternsSE2018_Lec 18_ Design Principles and Design Patterns
SE2018_Lec 18_ Design Principles and Design Patterns
 
A laboratory for teaching object oriented thinking
A laboratory for teaching object oriented thinkingA laboratory for teaching object oriented thinking
A laboratory for teaching object oriented thinking
 
Unit 3
Unit 3Unit 3
Unit 3
 
Design concept -Software Engineering
Design concept -Software EngineeringDesign concept -Software Engineering
Design concept -Software Engineering
 
1. oop with c++ get 410 day 1
1. oop with c++ get 410   day 11. oop with c++ get 410   day 1
1. oop with c++ get 410 day 1
 
CSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsCSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agents
 
CSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agentsCSE333 project initial spec: Learning agents
CSE333 project initial spec: Learning agents
 

Último

2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdfThe Good Food Institute
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNeo4j
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updateadam112203
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationKnoldus Inc.
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kitJamie (Taka) Wang
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsDianaGray10
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTxtailishbaloch
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024Brian Pichman
 
From the origin to the future of Open Source model and business
From the origin to the future of  Open Source model and businessFrom the origin to the future of  Open Source model and business
From the origin to the future of Open Source model and businessFrancesco Corti
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingFrancesco Corti
 
The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)IES VE
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxNeo4j
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIVijayananda Mohire
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3DianaGray10
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0DanBrown980551
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)codyslingerland1
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Libraryshyamraj55
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.IPLOOK Networks
 
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedIn
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedInOutage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedIn
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedInThousandEyes
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
 

Último (20)

2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf2024.03.12 Cost drivers of cultivated meat production.pdf
2024.03.12 Cost drivers of cultivated meat production.pdf
 
Novo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4jNovo Nordisk's journey in developing an open-source application on Neo4j
Novo Nordisk's journey in developing an open-source application on Neo4j
 
Patch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 updatePatch notes explaining DISARM Version 1.4 update
Patch notes explaining DISARM Version 1.4 update
 
Introduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its applicationIntroduction to RAG (Retrieval Augmented Generation) and its application
Introduction to RAG (Retrieval Augmented Generation) and its application
 
20140402 - Smart house demo kit
20140402 - Smart house demo kit20140402 - Smart house demo kit
20140402 - Smart house demo kit
 
Automation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projectsAutomation Ops Series: Session 2 - Governance for UiPath projects
Automation Ops Series: Session 2 - Governance for UiPath projects
 
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENTSIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
SIM INFORMATION SYSTEM: REVOLUTIONIZING DATA MANAGEMENT
 
CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024CyberSecurity - Computers In Libraries 2024
CyberSecurity - Computers In Libraries 2024
 
From the origin to the future of Open Source model and business
From the origin to the future of  Open Source model and businessFrom the origin to the future of  Open Source model and business
From the origin to the future of Open Source model and business
 
Where developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is goingWhere developers are challenged, what developers want and where DevEx is going
Where developers are challenged, what developers want and where DevEx is going
 
The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)The Importance of Indoor Air Quality (English)
The Importance of Indoor Air Quality (English)
 
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptxGraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
GraphSummit Copenhagen 2024 - Neo4j Vision and Roadmap.pptx
 
My key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAIMy key hands-on projects in Quantum, and QAI
My key hands-on projects in Quantum, and QAI
 
UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3UiPath Studio Web workshop Series - Day 3
UiPath Studio Web workshop Series - Day 3
 
LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0LF Energy Webinar - Unveiling OpenEEMeter 4.0
LF Energy Webinar - Unveiling OpenEEMeter 4.0
 
The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)The New Cloud World Order Is FinOps (Slideshow)
The New Cloud World Order Is FinOps (Slideshow)
 
How to release an Open Source Dataweave Library
How to release an Open Source Dataweave LibraryHow to release an Open Source Dataweave Library
How to release an Open Source Dataweave Library
 
Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.Introduction - IPLOOK NETWORKS CO., LTD.
Introduction - IPLOOK NETWORKS CO., LTD.
 
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedIn
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedInOutage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedIn
Outage Analysis: March 5th/6th 2024 Meta, Comcast, and LinkedIn
 
Key Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdfKey Trends Shaping the Future of Infrastructure.pdf
Key Trends Shaping the Future of Infrastructure.pdf
 

Responsibility Driven Design

  • 1. Harsh Jegadeesan’s CLASSROOM GRASP: DESIGNING OBJECTS WITH RESPONSIBILITIES BITS Pilani Off-Campus Work-Integrated Learning Programmes
  • 2. USE-CASE REALIZATION How a particular use-case is realized in the design model in terms of collaborating objects? Use-Case suggests system operations Domain-Layer interaction diagrams illustrate use-case realization 2
  • 3. GRASP : DESIGN OBJECTS WITH RESPONSIBILITIES GRASP patterns are a learning aid to help one understand essential object design, and apply design reasoning in a methodical, rational,explainable way. 3
  • 4. DESIGN ACTIVITIES During design and coding we apply various OO design principles, among them software design patterns such as the GRASP and GoF (Gang of Four) patterns. Our metaphor is Responsibility Driven Design (RDD), because our chief design emphasis is on assigning responsibilities to objects. 4
  • 5. RESPONSIBILITIES AND METHODS Responsibilities are realized as methods Approach to understanding and using design principles is based on patterns of assigning responsibilities. Definition of Responsibility: “A contract or obligation of a classifier” Responsibilities are of the following types: Knowing Doing 5
  • 6. DOING Doing responsibilities of an object include : Doing something itself , such as creating an object or doing a calculation Initialing action in other objects Controlling and coordinating activities in other objects 6
  • 7. KNOWING Knowing responsibilities of object include : Knowing about private encapsulated data Knowing about related objects Knowing about things it can derive or calculate 7
  • 8. RESPONSIBILITIES AND INTERACTION DIAGRAMS Interaction diagrams show choices in assigning responsibilities to objects. When these diagrams are created, decisions in responsibility assignment are reflected in the messages sent to different classes of objects. 8
  • 9. PATTERNS Principles and idioms codified in a structured format describing the problem, solution, and given a name are called patterns. A “New Pattern” is an oxymoron. Patterns are tried and true, established ways of doing things. They are not new things or new ways of doing things. 9
  • 10. DEFINITION OF PATTERN Pattern is a named problem/solution pair that can be applied in new contexts,with advice on how to apply it in novel situations and discussion of its trade-offs. 10
  • 11. NAMING PATTERNS All Patterns have suggestive names. Naming a pattern, technique, or a principle has the following advantages : It supports chunking and incorporating that concept into our understanding and memory It facilitates communication . 11
  • 12. CHANGING EMPHASIS Throughout analysis, we have referred to analyzing the problem domain, and postponing consideration of the solution domain. We emphasized domain objects over software objects . That changes in design. We are now concerned with software objects and the solution domain. 12
  • 13. GRASP The GRASP name was chosen to suggest the importance of grasping these principles to successfully design object-oriented software. It is an acronym for General Responsibility Assignment Software Patterns. They describe the fundamental principles of object design and responsibility assignment, expressed as patterns. 13
  • 14. FIVE BASIC GRASP PATTERNS : Information Expert Creator High Cohesion Low Coupling Controller 14
  • 15. UML CLASS DIAGRAM NOTATION Three sections: Class Name Third section is for methods attributes methods 15
  • 16. CREATOR Problem: Who should be responsible for creating a new instance of some class ? The creation of objects is one of the most common activities in an object-oriented system. It is useful to have a general principle for assignment of creation responsibilities. Assigned well, the design can support low coupling increased clarity, encapsulation, and reusability. 16
  • 17. MONOPOLY CONCEPTS (CANDIDATES) Monopoly Game Player Piece Die Board Square 17
  • 18. SOLUTION Assign class B the responsibility to create an instance of class A if one or more of the following is true : B aggregates A objects . B contains A objects. B records instances of A objects. B closely uses A objects. B has the initializing data that will be passed to A when it is created B is a creator of A objects. 18
  • 19. DISCUSSION The basic intent of the Creator pattern is to find a creator that needs to be connected to the created object in any event. Aggregator aggregates Part Container contains Content Recorder records. Sometimes a creator is found by looking for the class that has the initializing data that will be passed in during creation. 19
  • 20. CONTRAINDICATIONS Often creation requires significant complexity, such as: using recycled instances for performance reasons, conditionally creating an instance from one of a family of similar classes based upon some external property value In these instances, another pattern principle might be preferred (factory?) 20
  • 21. MONOPOLY EXAMPLE In the monopoly example, who will create the Squares? Since the game board contains the squares where activities take place, a Board software object is a logical place to create Square software objects. 21
  • 22. INFORMATION EXPERT By Information expert we should look for the class of objects that has all the information needed Problem : What is a general principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert – a class that has the information necessary to fulfill the responsibility. 22
  • 23. DISCUSSION Information Expert is a basic guiding principle used continuously in object design. Expert is not meant to be obscure or fancy idea; it expresses the common “intuition” that objects do things related to information they have. Fulfillment of a responsibility often requires information that is spread across different classes of objects. Whenever information is spread across different objects , they will need to interact via messages to 23 share the work.
  • 24. CONTRAINDICATIONS There are situations where the solution suggested by expert is undesirable, usually because of problems in coupling and cohesion. Keep the application logic in one place, database in another place and so forth, rather than intermingling different system concerns in the same component. 24
  • 25. BENEFITS Information encapsulation is maintained, since objects use their own information to fulfill tasks. This usually supports low coupling, which leads to more robust and maintainable systems. Behavior is distributed across the classes that have the required information, encouraging more cohesive “lightweight” class definitions that are easier to understand and maintain. High cohesion is usually supported. 25
  • 26. MONOPOLY EXAMPLE If you want to retrieve information about the squares on the board, who does it? The Board software object is also a good choice, as it was for creating the Square objects. Note that the information is retrieved from the Squares. 26
  • 27. LOW COUPLING Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other element. 27
  • 28. LOW COUPLING PATTERN Problem: How to support a low dependency, low change impact ,and increased reuse? Solution: Assign a responsibility so that coupling remains low. 28
  • 29. DISCUSSION Low Coupling is a principle to keep in mind during all design decisions It is an underlying goal to continually consider. It is evaluative principle that a designer applies while evaluating all design decisions. 29
  • 30. CONTRAINDICATIONS & BENEFITS (High coupling to stable elements and to pervasive elements is seldom a problem.) Benefits: Objects are not affected by changes in other components Objects are simple to understand in isolation Objects are convenient to reuse 30
  • 31. MONOPOLY EXAMPLE If we created an arbitrary other class to retrieve information from the Squares instead of assigning the responsibility to the Board object, then our other class would have to retrieve information from both Board and Square, increasing the number of connections (and thus the coupling.) 31
  • 32. CONNECTIONS BETWEEN PATTERNS Information Expert supports Low Coupling. This is a natural result of identifying patterns from practices that have developed over years of experience. You often get the same result by starting with a different idea, because the ideas (patterns) support each other. 32
  • 33. HIGH COHESION Cohesion is a measure of how strongly related and focused are the responsibilities of an element. High Cohesion: An element with highly related responsibilities, and which does not do a tremendous amount of work, has high cohesion. 33
  • 34. HIGH COHESION PATTERN Problem: How can complexity be kept manageable? Solution: Assign responsibility so that cohesion remains high. 34
  • 35. DISCUSSION Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions; it is an underlying goal to consider contantly. 35
  • 36. MONOPOLY EXAMPLE Assuming, from the previous Monopoly slide, that :MonopolyGame is the controller: If :MonopolyGame performs most of the game functions within the software object, you have low cohesion. If the functions are delegated to other software objects, you have high cohesion. 36
  • 37. BACK TO RELATIONSHIPS Low Coupling and High Cohesion go together naturally. One usually leads to the other. Both are outcomes of the OO principle of “chunking,” breaking up a large problem into manageable pieces. If the pieces are too simple there will be too many of them. If the pieces are too complex, each will not be understandable. 37
  • 38. COHESION EXAMPLES Some scenarios illustrating varying degrees of varying degrees of functional cohesion: Very Low Cohesion – A class is solely responsible for many different functional areas. Low Cohesion – A class has sole responsibility for a complex task in one functional area. 38
  • 39. Moderate Cohesion – A class has light weight and sole responsibilities in a few different areas that are logically related to the class concept, but not to each other. High Cohesion – A class has moderate responsibilities in one functional area and collaborates with other classes to fulfill tasks. 39
  • 40. CONTRAINDICATIONS Grouping of responsibilities or code into one class or component to simplify maintenance by one person. (Such grouping may also make maintenance much more difficult.) Distributed server objects. It is sometimes desirable to create fewer and larger, less cohesive server objects that provide an interface for many operations, due to overhead and performance needs associated with remote objects and remote communication. 40
  • 41. BENEFITS Clarity and ease of comprehension of design is increased. Maintenance and enhancements are simplified Low coupling is often supported. 41
  • 42. CONTROLLER A Controller is a non–user interface object responsible for receiving or handling a system event. It defines methods for system operation. 42
  • 43. PROBLEM : Who should be responsible for handling an input system event? Note that this assumes the Model-View- Controller architectural (not software) pattern that separates the user interface (Views) from the functionality of the rest of the system and uses controllers to access other functionality (Models). 43
  • 44. SOLUTION Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represent the overall system, device, or subsystem Represents a use case scenario within which the system event occurs 44
  • 45. DISCUSSION Controller pattern provides guidance for generally accepted, suitable choices. It is often desirable to use the same controller class for all the system events of one use case so that it is possible to maintain information about the state of the use case in the controller. 45
  • 46. MONOPOLY EXAMPLE The first system message is “Play Game.” What object should receive this message? The author suggests that :MonopolyGame might be a suitable object if there are a limited number of system operations. Otherwise, we would have to consider High Cohesion if there are many operations. 46
  • 47. FACADE CONTROLLER Suitable when there are not “too many” system events ,or it is not possible for the user interface (UI) to redirect system event messages to alternating controllers,such as in message processing system. 47
  • 48. USE–CASE CONTROLLER When placing the responsibilities in a façade controller leads to design with low cohesion or high coupling, Use Case Controller is preferred as an alternative. When there are many system events across different processes, it factors their handling into manageable separate classes. 48
  • 49. AN OBJECT CLASSIFICATION SCHEMA The following analysis class types are used by Ivar Jacobsen in Objectory: Boundary objects are abstractions of interfaces Entity objects are application-independent domain software objects Control objects are use case handlers Jacobsen was a contributor to UML, and the controller pattern reflects his approach. 49
  • 50. VISIBILITY Visibility is the ability of one object to “see” or have reference to another object Visibility is required for one object to message another Attribute visibility: Y is an attribute of Class X Parameter visibility: Y is parameter of Method X Local Visibility: Y is a local object in a method of Class X Global Visibility: Y is globally dependent 50
  • 51. OTHER GRASP PATTERNS Polymorphism Pure Fabrication Indirection Protected Variation 51
  • 52. POLYMORPHISM Problem: How to handle alternatives based on types? (conditional themes) How to design pluggable software components? Solution: when the related alternatives or behaviors vary by type, assign responsibilities for the behavior using polymorphic operations 52
  • 53. BENEFITS Extensions required for new variations are easy to add New implementation can be introduced without affecting clients 53
  • 54. PURE FABRICATION Problem: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert are not appropriate? Assigning responsibilities to only domain layer software classes leads to problems in terms of poor cohesion or coupling – low reuse! 54
  • 55. PURE FABRICATION (2) Solution: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept Design of objects is divided into: Representational decomposition Behavioral decomposition Benefits: High-Cohesion Reuse potential 55
  • 56. INDIRECTION 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 potential remains high? Solution: Assign the responsibility to an intermediary object to mediate between other components or services so that they are not directly coupled. 56
  • 57. PROTECTED VARIATIONS Problem: How to design objects, subsystems so that the variations or instability in these elements does not have an undesirable impact on other elements? Solution: Identify points of predicated variation or instability, assign responsibility to create a stable interface around them. 57
  • 58. SUMMARY The skillful assignment of responsibilities is extremely important in object design. Determining the assignment of responsibilities often occurs during the creation of interaction diagrams , and certainly during programming. Patterns are named problem/solution pairs that codify good advice and principles often related to assignment of responsibilities. 58