Академический Документы
Профессиональный Документы
Культура Документы
OO
So1ware
Design
The
tradi7onal
view
of
objects
is
that
they
are
data
with
methods.
Smart
Data.
But,
it
is
be.er
to
think
of
them
as
en##es
that
have
responsibili#es.
This
helps
us
focus
on
what
objects
are
supposed
to
do,
so
we
can
hide
the
implementa7on
details.
so
we
can
focus
on
an
objects
public
interface.
so
we
do
not
need
to
know
what
is
going
on
inside
the
object.
This
enables
you
to
delegate
responsibility.
2
RDD
A popular way of thinking about the design of software objects and also larger-scale components is in terms of responsibilities roles, and collaborations. This is part of a larger approach called Responsibility-Driven Design or RDD
Basically, these responsibilities are of the following two types: - Doing - Knowing.
3
RDD
Doing responsibilities of an object include: doing something itself, such as creating an object or doing a calculation initiating action in other objects controlling and coordinating activities in other objects Knowing responsibilities of an object include: knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate Think of software objects as similar to people with responsibilities who collaborate with other people to get work done. 4
Example
What
responsibili7es
does
a
Shape
have?
To
know
where
it
is
located.
To
be
able
to
draw
itself
on
a
display.
To
be
able
to
remove
itself
from
a
display.
This
implies
three
methods:
getLocation() drawShape() unDrawShape() We
do
not
need
to
know
anything
about
the
inner
workings
of
the
Shape
class,
like
a.ributes
or
another
object.
Focus
on
mo7va7on
rather
than
implementa7on.
5
Loose
Coupling
Hiding
the
implementa7on
of
Shape
behind
interfaces
essen7ally
decouples
them
from
the
using
objects.
Deni7on:
Two
modules
are
coupled
if
they
depend
on
each
other
in
any
way.
Decoupling
is
the
key
to
good
design.
It
means
that
if
something
changes
on
the
other
side
of
the
interface,
the
non-changed
side
should
not
require
altera7on.
High
Cohesion
. Definition: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component.
Rule of thumb: a class with high cohesion has - a relatively small number of methods, with highly related functionality, - and does not do too much work. High is better, so the code is relatively easy to maintain, understand, and reuse.
7
Encapsula7on
Tradi7onal
view
of
encapsula7on:
data
hiding.
Encapsula7on
isnt
just
data
hiding.
Encapsula7on
is
any
kind
of
hiding.
You
can
hide:
Implementa7ons
Derived
Classes
Design
Details
10
Inheritance
Revisit
Imagine
you
have
a
class
called
Pentagon
to
contain
state,
draw,
undraw,
and
so
on.
Later
you
decide
you
also
want
a
special
Pentagon
with
a
special
border.
We
can
create
a
Pentagon
with
a
special
border
class
that
is
derived
from
Pentagon.
11
Problems
Problems
of
Using
Inheritance
for
Specializa7on:
Weak
Cohesion:
What
happens
if
we
have
lots
of
borders?
If
each
border
is
a
separate
class
then
related
code
is
being
divided
up.
Reduces
reuse:
What
happens
if
I
want
to
reuse
the
special
border
for
other
shapes?
This
solu7on
does
not
allow
that
to
occur.
Doesnt
scale
well
with
varia#on:
What
happens
if
other
things
vary?
Two
dierent
kinds
of
shading
and
much
more?
Need
to
specialize
the
Pentagon
class
repeatedly.
12
A
Be.er
Approach
Consider
what
should
be
variable
in
your
design
(not
always
easy)
and
encapsulate
it.
Use
inheritance
to
classify
varia7ons
in
behaviours.
Thus,
the
using
class
can
have
a
reference
to
an
abstract
class
or
interface
that
has
more
than
one
specialized
deriva7on.
These
deriva7ons
are
encapsulated
from
the
using
class.
E.g.
Add
a
reference
to
a
Border
abstract
class.
13
Another
Example
Consider
the
tradi7onal
problem
of
crea7ng
classes
that
represent
animals.
Your
requirements
are:
Animal
objects
must
be
able
to
keep
and
retrieve
this
informa7on
Each
type
of
animal
can
have
a
dierent
number
of
legs
Each
type
of
animal
can
have
a
dierent
type
of
movement
A traditional approach: - Have data member containing the number of legs and its setter and getter method. - Create a inheritance hierarchy: start with animal, then have mammals, reptiles, etc. and keep creating more and more specific animals till you have all species.
14
A
Be.er
Solu7on
Works
with
many
varia7ons
are
present.
It
is
be.er
to
have
a
data
member
that
indicates
the
type
of
movement
the
object
has.
15
16
18
Switches Issues with coupling, testing More importantly, what happens when you have multiple variations?
19
Handle
Varia7on
Add
a
Third
Country
S7ll
a
Clean
implementa7on,
need
another
switch
// Handle Tax switch (myNation) { case US: //US Tax Rules here break; case Canada: //Canadian Tax Rules here break; case Germany: //Germany Tax Rules here break; }
20
//Handle Currency switch (myNation) { case US: //US Currency Rules here break; case Canada: //Canadian Currency Rules here break; case Germany: //Germany Currency Rules here break; } // Handle Language switch (myNation) { case US: case Canada: //use English break; case Germany: //use German break; }
21
Flow
of
the
switches
is
hard
to
read
When
new
cases
come
in,
you
must
nd
every
place
it
can
be
involved.
This
is
called
Switch
Creep
22
Another
Approach
Inheritance
Nothing
really
wrong
with
it
per
say
Certainly
allows
reuse
Could
create
new
SalesOrder
objects
from
exis7ng
objects
But,
can
it
handle
all
the
varia7ons
easily?
With
tall
inheritance
hierarchies?
23
A
Be.er
Approach
1.
Find
out
what
varies
and
encapsulate
it
in
a
class
of
its
own.
2.
Contain
this
class
in
another
class.
What
varies
in
this
example?
Tax
rules,
therefore
create
an
abstract
class
that
denes
how
to
accomplish
taxa7on
conceptually.
24
25
26
Strategy
Pa.ern
Intent:
Enable
you
to
use
dierent
business
rules
or
algorithms
depending
on
the
context
in
which
they
occur.
Problem:
The
selec7on
of
an
algorithm
that
needs
to
be
applied
depends
on
the
client
making
the
request
or
the
data
being
acted
on.
Solu#on:
Separate
the
selec7on
of
the
algorithm
from
the
implementa7on
of
the
algorithm.
29
30
Strategy
Pa.ern
Consequences:
Families
of
related
algorithms.
An
alterna7ve
to
subclassing.
Strategies
eliminate
condi7onal
statements.
A
choice
of
implementa7ons.
Clients
must
be
aware
of
dierent
strategies.
Communica7on
overhead
between
Strategy
and
Context.
Increased
number
of
objects.
31
Strategy
Pa.ern
Implementa#on:
Have
the
class
that
uses
the
algorithm
(Context)
contain
an
abstract
class
(Strategy)
that
has
an
abstract
method
specifying
how
to
call
the
algorithm.
Each
derived
class
implements
the
algorithm
needed.
32
An
Example
:
Sort
Assume
that,
you
need
to
write
a
sort
program
that
will
have
an
array
and
at
run-7me
you
want
to
decide
which
sort
algorithm
to
use.
Strategy
is
what
we
group
the
many
algorithms
that
do
the
same
things
and
make
it
interchangeable
at
run- 7me
Bubble
Runtime Sort
Ascending
Sort
SortStrategies
Selec#on
Sort
Descending Sort
Quick Sort
Input #1 #2 Heap
Sort
Result #1 #2
33
34
Another
Example
Many
dierent
layout
strategies
exist.
A
GUI
container
wants
to
decide
at
run-7me
which
layout
to
use.
Encapsulate
each
dierent
layout
algorithm
using
the
strategy
pa.ern.
35
36