Patterns in
Software Engineering
Software
Engineering
Lecturer: Raman Ramsin
Lecturer:
Raman
Ramsin
Lecture 6
OO Principles as Patterns: GRASP
Department of Computer Engineering 1Sharif University of Technology
OO
Principles
as
Patterns:
GRASP
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
OO Principles-Patterns in Software Engineering-Lecture 6 Slides-Computer Engineering, Slides of Software Engineering
OO Principles as Patterns: GRASP, Open Closed Principle, Liskov Substitution Principle, Dependency Inversion Principle, Interface Segregation Principle, Composite Reuse Principle, Principle of Least Knowledge, GRASP, General Responsibility Assignment Software Patterns, Information Expert, Creator, Low Coupling, High Cohesion, Controller, Polymorphism, Indirection, Pure Fabrication, Protected Variations, Design by Contract, Raman Ramsin, Lecture Slides, Patterns in Software Engineering, Departmen
Typology: Slides
2011/2012
1 / 23
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download OO Principles-Patterns in Software Engineering-Lecture 6 Slides-Computer Engineering and more Slides Software Engineering in PDF only on Docsity!
Patterns inSoftware EngineeringSoftware Engineering Lecturer: Raman RamsinLecturer:
Raman Ramsin
Lecture 6 OO Principles as Patterns: GRASP
1
Sharif University of Technology
OO
Principles as Patterns: GRASP
Patterns in Software Engineering – Lecture 6
Open Closed Principle (OCP)
Classes should be open for extension but closed formodification.
OCP states that we should be able to add new features to
OCP states that we should be able to add new features toour system without having to modify our set of preexistingclasses.
One of the tenets of OCP is to reduce the couplingbetween classes to the abstract level.
Instead of creating relationships between two concrete classes
Instead of creating relationships between two concrete classes,we create relationships between a concrete class and an abstractclass or an interface.
2
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
Dependency Inversion Principle (DIP)
Depend upon abstractions. Do not depend uponconcretions.
The Dependency Inversion Principle (DIP) formalizes theconcept of abstract coupling and clearly states that we
p
p
g
y
should couple at the abstract level, not at the concretelevel.
DIP tells us how we can adhere to OCP.
4
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
Interface Segregation Principle (ISP)
Many specific interfaces are better than a single,general interfacegeneral interface.
Any interface we define should be highlycohesive.cohesive.
5
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
Principle of Least Knowledge (PLK)
For an operation O on a class C
only operations on the
For
an operation O on a class C, only operations on the
following objects should be called: itself, its parameters,objects it creates, or its contained instance objects.
Also called the
Law of Demeter
The basic idea is to avoid calling any methods on anobject where the reference to that object is obtained byobject where the reference to that object is obtained bycalling a method on another object (
Transitive Visibility).
T
he primary benefit is that the calling method doesn’t
p
y
g
need to understand the structural makeup of the objectit’s invoking methods upon.
7
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
GRASP
Acronym stands for General Responsibility Assignment
y
p
y
g
Software Patterns.
A set of 9 Patterns introduced as a learning aid by CraigLarmanLarman.
Describe fundamental principles for object-oriented designand responsibility assignment, expressed as patterns.
p
y
g
,^
p
p
The skillful assignment of responsibilities is extremelyimportant in object design.
Determining the assignment of responsibilities oftenoccurs during the creation of interaction diagrams, andcertainly during programming.
8
Sharif University of Technology
y
g p
g
g
Patterns in Software Engineering – Lecture 6
GRASP: Information Expert
As a general principle of assigning responsibilities
As
a general principle of assigning responsibilities to objects, assign a responsibility to theinformation expert:
i.e. the class that has the
information necessary to
fulfill the responsibility.
10
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
GRASP: Creator
Assign class B the responsibility to create an instance ofclass A if one or more of the following is true:class A if one or more of the following is true:
B
aggregates A objects.
B
contains A objects
B
contains A objects.
B
records instances of A objects.
B
closely uses A objects.
B
closely uses A objects.
B
has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).
B is a
creator of A objects.
If more than one option applies, prefer a class B whichaggregates or
contains class A
11
Sharif University of Technology
aggregates
or
contains class A.
Patterns in Software Engineering – Lecture 6
GRASP: High Cohesion
A
ssign a responsibility so that cohesion remains
g
p
y
high.
A class with low cohesion does many unrelated
h
d
h
k
things, or does too much work.
Such classes are undesirable; they suffer from thefollowing problems:following problems:
^
hard to comprehend ^
hard to reuse ^
hard to reuse ^
hard to maintain ^
Delicate: constantly affected by change
13
Sharif University of Technology
Delicate:
constantly affected by change
Patterns in Software Engineering – Lecture 6
GRASP: Controller
Assign the responsibility for receiving or handling a system eventmessage to a class representing one of the following choices:
Represents the overall system, device, or subsystem
(facade
controller).
Represents a use case scenario within which the system event
Represents a use case scenario within which the system eventoccurs (a use-case- or session-controller).
^
Use the same controller class for all system events in the same usecase scenario. ^
Informally, a session is an instance of a conversation with anactor.
Note that "window " "applet " "widget " "view " and "document"
Note that
window,
applet,
widget,
view,
and
document
classes are not on this list.
Such classes should
not fulfill the tasks associated with system
events
they typically delegate these events to a controller
14
Sharif University of Technology
events
, they typically delegate these events to a controller.
Patterns in Software Engineering – Lecture 6
GRASP: Indirection
Assign the responsibility to an intermediate object tomediate between other components or services so thatthey are not directly coupled.
The intermediary creates an
indirection between the other
components.
Beware of transitive visibility.
16
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
GRASP: Pure Fabrication
Assign a highly cohesive set of responsibilities to anartificial or convenience class that does not represent aproblem domain concept — something made up, tos ppo t high cohesion
lo
co pling
and
e se
support high cohesion, low coupling, and reuse.
Example: a class that is solely responsible for savingobjects in some kind of persistent storage medium, suchas a relational database; call it the
PersistentStorage.
This class is a Pure Fabrication — a figment of the imagination.
17
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
Design by Contract (DBC)
A discipline of analysis
design
implementation
and
A
discipline of analysis, design, implementation, and management.
Bertrand Meyer introduced
Design by Contract
in Eiffel
as a powerful technique for producing reliable software.
Its key elements are assertions: boolean expressions that
Its key elements are assertions: boolean expressions thatdefine correct program states at arbitrary locations in thecode.
19
Sharif University of Technology
Patterns in Software Engineering – Lecture 6
Design by Contract (DBC):
Assertions
Simple assertions belong to individual statements in a program,yet important DBC assertions are defined on classes:yet important DBC assertions are defined on classes:
Per- method assertions:
Precondition:
A condition that must be true of the parameters of
^
Precondition:
A
condition that must be true of the parameters of
a method and/or data members – if the method is to behavecorrectly – PRIOR to running the code in the method. ^
Postcondition:
A condition that is true AFTER running the code in
^
Postcondition:
A condition that is true AFTER running the code in
a method.
Per-class assertions:
^
Class Invariant:
A condition that is true BEFORE and AFTER
running the code in a method (except constructors anddestructors).
20
Sharif University of Technology