This document discusses the Open Closed Principle of software design. It explores the tension between meeting today's needs while allowing for future changes. The principle advocates designing software that is open for extension, but closed for modification, by favoring changing software through addition of new code rather than modifying existing code. This reduces the risks and costs of unexpected defects when software is modified. The document examines how qualities like flexibility, reliability and stability can be promoted by following this principle.

1. The
Open
Closed
Principle
Part
I
The
Original
Version
©
2014
Philip
Schwarz
h>ps://twi>er.com/philip_schwarz
philip.johann.schwarz@gmail.com
This
work
is
licensed
under
a
CreaHve
Commons
A>ribuHon-­‐NonCommercial-­‐NoDerivs
3.0
Unported
License.

2. Tension
Between
known
needs
of
today
changes
that
will
arrive
in
the
future
Sandi
Metz
The
Fundamental
Target
of
Design

3. Code
needs
to
work
today
just
once,
and
it
needs
to
be
easy
to
change
forever

4. It
is
at
this
point
of
tension
where
design
ma2ers
today’s
needs
future
changes

5. its
purpose,
its
enHre
reason
for
being,
is
to
reduce
the
cost
of
change.

6. 1999
3rd
Apr
2014
@KentBeck
design
is
irrelevant
for
today.
it
only
ma2ers
when
we
want
to
change
the
so9ware...
@KentBeck
change
is
the
only
reason
to
organize
so9ware
at
all…

7. adopted
by
agile
community
as
a
truth
about
soZware
development
Henrik
Christensen
2010

8. “soZware
must
be
designed
and
developed
to
make
it
easy
to
change”

9. Let’s
examine
soZware
qualiHes
that
enable
ease
of
change
Look
for
definiHons
in
ISO
9126
Projects
someHmes
fail
due
to
not
having
any
clear
defini=ons
of
"success”
This
standard
tries
to
develop
a
common
understanding
of
project
objec=ves
and
goals,
e.g.
soZware
qualiHes

10. SoZware
is
Reliabile
if
it
can
maintain
a
specific
level
of
performance
under
specific
usage
condiHons

11. in
our
secng…
In
parHcular,
we
are
interested
in
preserving
reliability
in
the
face
of
change
SoZware
is
Reliabile
if
it
can
perform
the
required
func=ons
without
failing

12. “maintainability
is
composed
of
several,
finer
grained,
qualiHes”

13. Analysability
Maintainability
Changeability
Stability
Testability
SoZware
is
Analysable
if
you
can
• diagnose
it
for
§ deficiencies
§ causes
of
failure
• idenHfy
the
parts
to
be
modified
“Analysability
is
basically
the
ability
to
understand
soZware”

14. Analysability
Maintainability
Changeability
Stability
Testability
SoZware
is
changeable
if
it
allows
you
to
• implement
a
specific
modificaHon
• add,
modify,
or
enhance
a
feature
at
a
reasonable
cost
“almost
all
Design
Pa2erns
are
geared
towards
increasing
design’s
changeability”

15. Analysability
Maintainability
Changeability
Stability
Testability
“SoZware
is
flexible
if
you
can
add/enhance
func=onality
purely
by
adding
so9ware
units
and
specifically
not
by
modifying
exis=ng
so9ware
units”
Flexibility
a
special
case
of
changeability

16. Changeability
Behavioural
changes
that
are
introduced
by
modifying
exisHng
producHon
code
Changeability
is
a
desirable
quality,
but
it
relies
on
Change
by
Modifica=on
Change
by
ModificaHon
“The
less
I
ever
modify
a
class,
the
higher
the
probability
that
it
will
remain
free
of
defects”
ModificaHons
carry
the
risk
of
introducing
defects,
and
the
necessary
cost
of
avoiding
them:
tesHng,
code
reviewing,
etc.

17. Behavioural
changes
that
are
introduced
by
modifying
exisHng
producHon
code
Change
by
ModificaHon
Change
by
AddiHon
Behavioural
changes
that
are
introduced
by
adding
new
producHon
code
instead
of
modifying
exisHng
code
Contrast
Change
by
Addi=on
avoids
(risky)
modifica=ons
altogether
with

18. Changeability
Change
by
AddiHon
Change
by
ModificaHon
Changeability
does
not
take
a
stand
point
with
regards
to
the
way
a
specified
modificaHon
is
implemented
Flexibility
In
contrast,
Flexibility
does
take
this
stand
point
and
requires
that
no
modifica=ons
are
made

19. Analysability
Maintainability
Changeability
Stability
Testability
SoZware
is
Stable
if
it
avoids
unexpected
effects
when
modified
“I
advocate
the
pracHce
to
avoid
modifying
exis=ng
code
but
preferably
add
features
or
modify
exis=ng
ones
by
other
means”
“any
change
to
exisHng
soZware
carries
a
risk
of
introducing
defects”

20. Changeability
Stability
Flexibility
Reliability
Change
by
ModificaHon
Change
by
AddiHon
-­‐
+ -­‐
+
Summary
+ supports
-­‐ risks
undermining
relies
on

21. Ques=on:
how
do
we
promote
flexibility,
reliability
and
stability
in
our
soZware?
Analysability
Maintainability
Changeability
Stability
Testability
Flexibility
Reliability

22. Answer:
we
favour
‘Change
by
Addi=on’
over
‘Change
by
Modifica=on’
Changeability
Stability
Flexibility
Reliability
Change
by
ModificaHon
Change
by
AddiHon
-­‐
+ -­‐
+

23. I
cover
techniques
that
focus
on
flexibility
Christensen
if
you
require
that
s/w
can
adapt
to
changing
requirements
without
modifying
the
produc=on
code
then
you
need
to
employ
a
SPECIAL
set
of
design
and
programming
techniques
as
well
as
adopt
a
SPECIAL
mindset

24. “Another
way
of
characterising
Change
by
Addi=on
that
you
may
come
across
is
the
Open
Closed
Principle”
How
do
we
achieve
?
Change
by
AddiHon

25. The
Open-­‐Closed
Principle
Modules
should
be
both
open
and
closed
Bertrand
Meyer
Object
Oriented
SoZware
ConstrucHon
The
most
comprehensive,
definiHve
OO
reference
ever
published
1988

26. Isn’t
there
a
contradic=on
between
the
two
terms?
Modules
should
be
both
OPEN
and
CLOSED
¬(p
∧
¬p)

27. The
contradic=on
is
only
apparent
The
two
terms
correspond
to
goals
of
a
different
nature
e.g.
a
Dutch
door
can
be
both
OPEN
and
CLOSED
It
is
a

28. So
let’s
look
at
the
goals
of
the
OCP
OCP

29. A
module
is
said
to
be
OPEN
if
it
is
sHll
available
for
extension
or
add
fields
to
its
data
structures
Data
Structures
fields
+
operations
e.g.
it
should
be
possible
to
expand
its
set
of
opera=ons

30. A
module
is
said
to
be
CLOSED
If
it
is
available
for
use
by
other
modules
Has
a
well-­‐defined,
stable
descripHon
(its
interface
–
in
informaHon
hiding
sense)
public
part
secret
part
interface
1
can
be
compiled,
stored
in
a
library,
and
made
available
for
clients
to
use
2
in
the
case
of
a
design
or
specificaHon
module:
• approved
• baselined
in
version
control
• its
interface
published
for
benefit
of
other
module
authors
3

31. OPEN
if
it
is
sHll
available
for
extension
CLOSED
If
it
is
available
for
use
by
other
modules
Recap
–
A
module
is…

32. It
is
impossible
to
foresee
all
the
elements
that
a
module
will
need
in
its
lifeHme
X
The
need
for
ness
so
developers
wish
to
keep
the
module
open
for
as
long
as
possible
so
that
they
can
address
changes,
and
extensions
by
changing
elements
or
adding
new
elements

33. The
need
for
ness
if
a
module
is
never
closed
unHl
it
is
certain
that
it
contains
all
the
needed
features
x
every
developer
would
always
be
waiHng
for
compleHon
of
another
developer's
job
then
mulH-­‐module
s/w
can
never
reach
compleHon
x
in
a
system
consisHng
of
many
modules,
most
modules
will
depend
on
some
others
but
it
is
also
necessary
to
close
modules

34. Modules
should
be
both
open
and
closed
We
want
modules
to
be
both
for
extension
and
for
modificaHon

35. the
two
goals
of
openness
and
closedness
with
tradi=onal
techniques
are
incompa=ble

36. either
you
keep
a
module
open
and
others
cannot
use
it
yet
and
any
change
or
extension
can
trigger
a
painful
chain
reac=on
of
changes
or
you
close
it
in
many
other
modules
which
relied
on
the
original
module
directly
or
indirectly

37. A
B
C
D
E
A
module
and
its
clients
A’
F
G
H
I
New
clients
which
need
A’,
an
adapted
or
extended
version
of
A
Typical
situaHon
where
the
needs
for
Open
and
Closed
modules
are
hard
to
reconcile
=
client
of

38. With
non-­‐OO
methods,
there
seem
to
be
only
2
solu=ons,
equally
unsa=sfactory

39. A
B
C
D
E
A
F
G
H
I
SoluHon
1

40. A
B
C
D
E
A
F
G
H
I
SoluHon
1

41. A
B
C
D
E
A’
F
G
H
I
SoluHon
We
have
taken
a
copy
of
A
and
modified
it,
turning
it
into
the
desired
A’

42.
SoluHon
Meyer’s
Assessment
the
consequences
are
appalling
an
explosion
of
variants
of
the
original
module,
many
of
them
very
similar,
but
never
quite
iden=cal
if
you
extrapolate
its
effects
to
• many
modules
• many
modificaHon
requests
• a
long
period
of
Hme

43.
SoluHon
(Source
tree
copy)
Christensen’s
Assessment
Probably
the
main
reason
it
is
encountered
so
o9en
in
prac=ce
Easy
to
explain
to
colleagues
&
new
developers
No
implementa=on
interference
X

44.
SoluHon
(Source
tree
copy)
Christensen’s
Assessment
Quick
but
very
dangerous
In
the
long
run
it
is
oZen
a
real
disaster…
The
soluHon
has
severe
limita=ons.

45. because
it
leads
to
the
mul=ple
maintenance
problem

46.
SoluHon
(Source
tree
copy)
Christensen’s
Assessment
when
you
want
to
add/modify
logic
you
have
to:
• Do
it
for
each
source
tree
• Write
the
same
test
cases
for
each
source
tree
you
have
to
do
it
in
each
source
tree
when
you
need
to
remove
a
defect

47. DRIFT
PracHce
shows
that
over
Hme
the
source
trees
evolve
into
completely
different
direcHons:
they
dri9
apart.
AZer
a
while
it
is
more
or
less
like
maintaining
a
set
of
completely
different
applica=ons
At
that
point,
before
you
do
any
of
the
operaHons,
you
have
to
first
analyse
each
source
tree!!

48. Used
in
airports
to
generate
reports
of
local
weather
one
variant
for
each
airport
in
Denmark
init
and
config
code
Example
SAWOS
-­‐
Semi
AutomaHc
Weather
ObservaHon
System
8
copies!!!

49. Analysability
Stability
Reliability
soluHon
-­‐ -­‐ -­‐
Summary
mul=ple
maintenance
problem

50. That
was
Meyer’s
first
unsa=sfactory
soluHon
to
the
problem
of
making
modules
both
OPEN
and
CLOSED
Let’s
turn
to
the
second
one

51. A
B
C
D
E
A’
F
G
H
I
A
module
and
its
clients
New
clients
which
need
A’,
an
adapted
or
extended
version
of
A
=
client
of
Problem

52. SoluHon
2
A
B
C
D
E
A’
F
G
H
I
Change
by
ModificaHon

53. A+
B
C
D
E
A’
F
G
H
I
We
have
modified
A
into
A+,
which
can
switch
between
two
modes
of
execuHon
In
one
mode
it
behaves
like
A,
and
in
the
other
it
behaves
as
expected
of
A’
SoluHon

54. A+
B
C
D
E
A’
F
G
H
I
We
have
modified
A
into
A+,
which
can
switch
between
two
modes
of
execuHon
In
one
mode
it
behaves
like
A,
and
in
the
other
it
behaves
as
expected
of
A’
SoluHon

55. A+
B
C
D
E
A’
F
G
H
I
If
(variant
==
VARIANT_1)
then
{
….
}
else
{
….
}
At
points
of
varia=on,
A+
looks
like
this:
We
have
modified
A
into
A+,
which
can
switch
between
two
modes
of
execuHon
In
one
mode
it
behaves
like
A,
and
in
the
other
it
behaves
as
expected
of
A’
AlternaHvely,
this
can
be
a
switch
SoluHon

56. A+
B
C
D
E
A’
F
G
H
I
SoluHon
–
Meyer’s
Assessment

57. A+
B
C
D
E
A’
F
G
H
I
The
poten=al
for
disaster
is
obvious:
changes
to
A
may
invalidate
the
assumpHons
on
the
basis
of
which
the
old
clients
used
A.
So
the
changes
may
start
a
dramaHc
series
of
changes
in
clients,
client
of
clients....etc
SoluHon
–
Meyer’s
Assessment

58. A+
A’
F
G
H
I
SoluHon
–
Meyer’s
Assessment
The
poten=al
for
disaster
is
obvious:
changes
to
A
may
invalidate
the
assumpHons
on
the
basis
of
which
the
old
clients
used
A.
So
the
changes
may
start
a
dramaHc
series
of
changes
in
clients,
client
of
clients....etc
B
C
E
D
this
is
a
nightmare
for
the
proj.
mgr.
the
system
regresses
and
several
modules
have
to
be
re-­‐
opened
for
dev/test/debug/
documentaHon

59. Even
though
the
Change
soluHon
has
this
problema=c
ripple
effect,
it
is
sHll
be2er
than
the
Copy
solu=on.
On
the
surface,
the
copy
solu=on
seems
be2er
because
it
avoids
the
ripple
effect
of
change
but
in
fact
it
may
even
be
more
catastrophic…it
only
postpones
the
day
of
reckoning
We
saw
earlier
the
risks
of
an
explosion
of
variants,
many
of
them
very
similar,
but
never
quite
iden=cal:
SoluHon
–
Meyer’s
Assessment
soluHon
soluHon

60.
SoluHon
(Parametric
soluHon)
Christensen’s
Assessment
CondiHonals
are
easy
to
understand.
So
approach
is
easy
to
describe
to
other
developers.
Avoids
Mul=ple
Maintenance
Problem
Only
one
code
base
to
maintain
soluHon
soluHon

61. LiabiliHes,
most
of
which
deal
with
long
term
maintainability
Change
by
ModificaHon
Reliability
Concerns
–
soluHon
relies
on
with
risk
of
introducing
new
defects
Analysability
concerns
–
as
more
and
more
requirements
are
handled
by
parameter
switching,
the
code
becomes
less
easy
to
analyse
…
Responsibility
erosion
–
the
soZware
has,
without
much
noHce,
been
given
an
extra
responsibility
drives
towards
Procedural
Design
Blob
aka
God
Class
SoluHon
(Parametric
soluHon)
Christensen’s
Assessment

62. A
reasonable
approach
at
first,
but
one
with
serious
problems
for
applicaHons
that
need
to
grow
over
Hme
SoluHon
(Switches)
Shalloway’s
Assessment
Not
too
bad
as
long
as
you
just
keep
adding
cases…
2004

63. but
soon
you
need
to
introduce
fall-­‐throughs…
…and
then
the
switches
are
not
as
nice
as
they
used
to
be

64. Eventually
you
need
to
start
adding
varia=ons
within
a
case.
I
like
to
call
this
switch!
The
flow
of
the
switches
themselves
becomes
confusing,
hard
to
read,
hard
to
decipher.
When
a
new
case
comes
in
the
programmer
must
find
every
place
it
can
be
involved
(o9en
finding
all
but
one
of
them).
Suddenly
things
get
bad
in
a
hurry.

65. Analysability
Stability
Reliability
solu=on
-­‐ -­‐ -­‐
Summary
Analysability
Stability
Reliability
solu=on
-­‐
-­‐
-­‐
With
non-­‐OO
methods,
there
are
only
only
2
solu=ons
available
to
us,
BOTH
UNSATISFACTORY
mul=ple
maintenance
problem
Change
by
ModificaHon
CHANGE
COPY

66. If
non-­‐OO
methods
are
all
we
have,
then
Meyer
says
we
face
a
change
or
copy
dilemma
CHANGE
COPY

67. A
B
C
D
E
A’
F
G
H
I
So
how
can
we
have
modules
that
are
both
and
?
How
can
we
keep
A
and
everything
in
the
top
part
of
the
figure
unchanged,
…
…while
providing
A’
to
the
bo>om
clients,
and
avoiding
duplica=on
of
so9ware?

68. A
B
C
D
E
A’
F
G
H
I
With
the
OO
concept
of
inheritance
Inheritance
allows
us
to
get
out
of
the
CHANGE
OR
COPY
dilemma…
…because
inheritance
allows
us
to
define
a
new
module
A'
in
terms
of
an
exis=ng
module
A,
…by
sta=ng
only
the
differences
between
the
two
A’
defines
new
features,
and
redefines
(i.e.
modifies)
one
or
more
of
A’s
features
inherits
from
Change
by
AddiHon

69. Thanks
to
inheritance,
OO
developers
can
adopt
a
much
more
incremental
approach
to
soZware
development
than
used
to
be
possible
with
earlier
methods
OO
inheritance

70. Hacking = Slipshod approach to building and
modifying code
Slipshod = Done poorly or too quickly; careless.
The
Hacker
may
seem
bad
but
oZen
his
heart
is
pure.

71. He
sees
a
useful
piece
of
soZware,
which
is
almost
able
to
address
the
needs
of
the
moment,
more
general
than
the
soZware’s
original
purpose.
Hacker
Spurred
by
a
laudable
desire
not
to
redo
what
can
be
reused,
our
hacker
starts
modifying
the
original
to
add
provisions
for
new
cases
solu=on

72. The
impulse
is
good
but
the
effect
is
oZen
to
pollute
the
soZware
with
many
clauses
of
the
form
if
that_special_case
then…
if
(<special
case
D>)
then …
if
(<special
case
C>)
then …
if
(<special
case
B>)
then …
if
(<special
case
A>)
then …
switch!

73. so
that
aZer
a
few
rounds
of
hacking,
perhaps
by
different
hackers,
the
soZware
starts
resembling
a
chunk
of
Swiss
cheese
that
has
been
leZ
outside
for
too
long
in
August
–
it
has
both
holes
and
growth
Hacking

74. Open-Closed Principle =
One
way
to
describe
the
OCP
and
the
consequent
OO
techniques
is
to
think
of
them
as
organised
hacking
Hacking
The
organised
form
of
hacking
will
enable
us
to
cater
to
the
variants
without
affec=ng
the
consistency
of
the
original
version.
Inheritance
Change
by
ModificaHon
Change
by
AddiHon

75. if
you
have
control
over
original
s/w
and
can
rewrite
it
so
that
it
will
address
the
needs
of
several
kinds
of
clients
…you
should
do
so
Caveats
at
no
extra
complicaHon

76.
The
OCP
principle
and
associated
techniques
are
intended
for
the
adapta=on
of
healthy
modules
If
there
is
something
wrong
with
a
module
you
should
fix
it…
…not
leave
the
original
alone
and
try
to
correct
the
problem
in
the
derived
module
Derived
Base
neither
OCP
nor
redefiniHon
in
inheritance
is
a
way
to
address
design
flaws,
let
alone
bugs
Design
Flaw

78. its
purpose,
its
enHre
reason
for
being,
is
to
reduce
the
cost
of
change.

79. Ques=on:
how
do
we
promote
flexibility,
reliability
and
stability
in
our
soZware?
Analysability
Maintainability
Changeability
Stability
Testability
Flexibility
Reliability

80. Answer:
we
favour
‘Change
by
Addi=on’
over
‘Change
by
Modifica=on’
Changeability
Stability
Flexibility
Reliability
Change
by
ModificaHon
Change
by
AddiHon
-­‐
+ -­‐
+

81. How
do
we
achieve
?
Change
by
AddiHon
which
uses
OO
inheritance
Inheritance
We
apply
the
Open-­‐Closed
Principle

82. extends
is
evil!!!!!
Yes,
we’ll
cover
that
in
the
next
presentaHon:
Part
II
But,
using
inheritance
is
no
longer
the
main
approach
to
saHsfying
the
OCP
Allen
Holub
2004
2003

83. in
which
we
look
at
the
modern,
contemporary
version
of
the
OCP
again,
we’ll
cover
this
in
the
next
presentaHon:
Part
II
Using
inheritance
is
sHll
one
of
the
ways
of
saHsfying
the
OCP,
and
was
considered
THE
approach
for
a
long
while
Why
extends
is
evil
1988
-­‐
1st
ed.
1997
–
2nd
ed.
1995
That
started
changing
with
the
emergence
of
the
design
techniques
presented
in
Design
Pa2erns
2003

85. References
All
images
sourced
from
h>p://www.google.co.uk/advanced_image_search,
so
see
there
for
details
of
which
are
subject
to
copyright
Object-­‐Oriented
So9ware
Construc=on
–
by
Bertrand
Meyer;
PublicaHon
Date:
3
April
1997
|
ISBN-­‐10:
0136291554
|
ISBN-­‐13:
978-­‐0136291558
|
EdiHon:
2
Flexible,
Reliable
So9ware:
Using
Pa2erns
and
Agile
Development
–
by
Henrik
B.
Christensen;
PublicaHon
Date:
11
May
2010
|
ISBN-­‐10:
1420093622
|
ISBN-­‐13:
978-­‐1420093629
Design
Pa2erns
Explained:
A
New
Perspec=ve
on
Object-­‐Oriented
Design;
by
Alan
Shalloway;
PublicaHon
Date:
12
Oct
2004
|
ISBN-­‐10:
0321247140
|
ISBN-­‐13:
978-­‐0321247148
|
EdiHon:
2
Less
-­‐
The
Path
to
Be2er
Design;
by
Sandi
Metz
at
GoRuCo
2011
goruco_2011_-­‐_sandi_metz_-­‐_less_-­‐_the_path_to_be>er_design_1280x720.mp4
Why
Extends
is
Evil
-­‐
Improve
your
code
by
replacing
concrete
base
classes
with
interfaces;
by
Allen
Holub;
h>p://www.javaworld.com/arHcle/2073649/core-­‐java/why-­‐extends-­‐is-­‐evil.html