The document discusses principles of object-oriented design, specifically focusing on the GRASP (General Responsibility Assignment Software Patterns) patterns. It introduces five basic GRASP patterns: Creator, Information Expert, High Cohesion, Low Coupling, and Controller. For each pattern, it provides the problem addressed, proposed solution, example applications, and potential contraindications. It also provides a UML class diagram notation guide and discusses how patterns can be applied when designing objects for a Monopoly game domain.
This presentation is about UML class diagram. In this presentation you will learn about class diagram, association, agreegation, generalization and realization.
GIve differences in 4 unique and basic terms of UML, classification , definitions ,frameworks. understandable through diagrams. Some similarities / Trade-off are also for more detailed knowledge.
The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field
of software engineering, that is intended to provide a
standard way to visualize the design of a system.
Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.
How do you begin to engineer the world's best software application? As you live in an Agile world today, how do you use architecture disciplines like Kruchten 4+1, UML, TOGAF, and Zachman? What do they mean? Where do you start?
In this presentation, Brad Beiermann will take you on a journey through the past, present and future disciplines of being a software architect. As you come out of this session, you will be equipped with the concepts of continuous design, and what it means to be design driven in today's fast paced development environment.
Web businesses such as eBay®, Amazon® and a whole lot of others have long seized to be mere websites; they have morphed into web business platforms. By adopting a platform strategy, they are building an ecosystem of developers, partners and entrepreneurs to build innovative applications for customers. In this session, we discuss the significance of and associated issues in adopting a SOA strategy to open-up these platforms for the ecosystem.
Web Business Platforms On The Cloud An Engineering PerspectiveHarsh Jegadeesan
Web businesses such as eBay®, Amazon® and a whole lot of others have long seized to be mere websites; they have morphed into web business platforms on the "cloud". By adopting a platform strategy, they are building an ecosystem of developers, partners and entrepreneurs to build innovative applications for customers. As platform owners, catering to his heterogeneous ecosystem is a huge engineering challenge in itself. This session, we would discuss some of these challenges along with some recipes to overcome them.
This presentation is about UML class diagram. In this presentation you will learn about class diagram, association, agreegation, generalization and realization.
GIve differences in 4 unique and basic terms of UML, classification , definitions ,frameworks. understandable through diagrams. Some similarities / Trade-off are also for more detailed knowledge.
The Unified Modeling Language (UML) is a general-
purpose, developmental, modeling language in the field
of software engineering, that is intended to provide a
standard way to visualize the design of a system.
Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most—if not all—languages, depending on the capabilities of the language. Most importantly, any design pattern can be a double-edged sword— if implemented in the wrong place, it can be disastrous and create many problems for you. However, implemented in the right place, at the right time, it can be your savior.
How do you begin to engineer the world's best software application? As you live in an Agile world today, how do you use architecture disciplines like Kruchten 4+1, UML, TOGAF, and Zachman? What do they mean? Where do you start?
In this presentation, Brad Beiermann will take you on a journey through the past, present and future disciplines of being a software architect. As you come out of this session, you will be equipped with the concepts of continuous design, and what it means to be design driven in today's fast paced development environment.
Web businesses such as eBay®, Amazon® and a whole lot of others have long seized to be mere websites; they have morphed into web business platforms. By adopting a platform strategy, they are building an ecosystem of developers, partners and entrepreneurs to build innovative applications for customers. In this session, we discuss the significance of and associated issues in adopting a SOA strategy to open-up these platforms for the ecosystem.
Web Business Platforms On The Cloud An Engineering PerspectiveHarsh Jegadeesan
Web businesses such as eBay®, Amazon® and a whole lot of others have long seized to be mere websites; they have morphed into web business platforms on the "cloud". By adopting a platform strategy, they are building an ecosystem of developers, partners and entrepreneurs to build innovative applications for customers. As platform owners, catering to his heterogeneous ecosystem is a huge engineering challenge in itself. This session, we would discuss some of these challenges along with some recipes to overcome them.
APIs make you mobile - Mobile World Congress 2017Harsh Jegadeesan
Mobility is a monumental change that has made our lives digital. How can we enable mobility? by unlocking the data and processes and making them mobile. APIs allow you to make your data and processes mobile. APIs are the atoms of digital life! You need to take good care of your APIs. The SAP Cloud Platform allows you to manage your full lifecycle of APIs.
SAP API Business Hub - Community Webinar.
SAP API Business Hub is a public catalog of all SAP and selected partner APIs. (See: https://api.sap.com/).
The slides were presented in the SAP Community Webinar on Jan 16, 2017 for SAP mentors and influencers community. https://blogs.sap.com/2017/01/03/jan-16-sap-community-calls-sap-api-business-hub/
A blog on the webinar by Tammy Powlas is available here:
https://blogs.sap.com/2017/01/16/sap-api-business-hub-a-public-catalog-of-all-sap-apis-sap-mentor-community-call/
API Business Hub (api.sap.com) is the central catalog of SAP and selected partner APIs for application developers to search, discover, test and consume these APIs to build extensions or integrations using the HANA Cloud Platform. This presentation provides an overview of the SAP API Business Hub.
User manual for those users who develop any desktop application so i try to provide betteropportunity to view it and try to make best user manual ..
Good Luck
These slides on Object-Oriented Design Heuristics are part of the course LINGI2252 “Software Maintenance and Evolution”, given by Prof. Kim Mens at UCL, Belgium.
Je vous partage l'un des présentations que j'ai réalisé lorsque j'étais élève ingénieur pour le module 'Anglais Business ' , utile pour les étudiants souhaitant préparer une présentation en anglais sur les Design Pattern - ou les patrons de conception .
Software Reuse and Object-Oriented Programmingkim.mens
These slides on Software Reuse and Object-Oriented Programming are part of the course LINGI2252 “Software Maintenance and Evolution”, given by Prof. Kim Mens at UCL, Belgium
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
The Art of the Pitch: WordPress Relationships and SalesLaura Byrne
Clients don’t know what they don’t know. What web solutions are right for them? How does WordPress come into the picture? How do you make sure you understand scope and timeline? What do you do if sometime changes?
All these questions and more will be explored as we talk about matching clients’ needs with what your agency offers without pulling teeth or pulling your hair out. Practical tips, and strategies for successful relationship building that leads to closing the deal.
Builder.ai Founder Sachin Dev Duggal's Strategic Approach to Create an Innova...Ramesh Iyer
In today's fast-changing business world, Companies that adapt and embrace new ideas often need help to keep up with the competition. However, fostering a culture of innovation takes much work. It takes vision, leadership and willingness to take risks in the right proportion. Sachin Dev Duggal, co-founder of Builder.ai, has perfected the art of this balance, creating a company culture where creativity and growth are nurtured at each stage.
Let's dive deeper into the world of ODC! Ricardo Alves (OutSystems) will join us to tell all about the new Data Fabric. After that, Sezen de Bruijn (OutSystems) will get into the details on how to best design a sturdy architecture within ODC.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
"Impact of front-end architecture on development cost", Viktor TurskyiFwdays
I have heard many times that architecture is not important for the front-end. Also, many times I have seen how developers implement features on the front-end just following the standard rules for a framework and think that this is enough to successfully launch the project, and then the project fails. How to prevent this and what approach to choose? I have launched dozens of complex projects and during the talk we will analyze which approaches have worked for me and which have not.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
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
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
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