Four Patterns at the Heart of Good Programming Style

1. 1

2. 2

3. Have
you
read
‘Code
Complete’
by
Steve
McConnell?
When
I
started
using
Java
in
1997/1998
there
was
quite
a
bit
of
talk
about
it.
3

4. As
you
can
see
from
above,
opinion
is
divided
over
its
merits.
I
think
it
is
safe
to
say
that
a
lot
of
people
have
skimmed/read
it
and
may
have
been
influenced
by
it.
We
don’t
have
Nme
to
look
at
the
detail
of
this
but
in
his
book
(both
ediNons)
McConnell
asks
himself
‘How
long
can
a
method
be?’,
and
to
answer
this
he
looks
at
the
results
of
various
studies.
We
are
going
to
go
straight
to
his
conclusion/answer
4

5. 5

6. He
acknowledges
that
method
length
can
affect
readability,
but
only
as
it
surpasses
200
lines!
This
presentaNon
is
about
a
different
point
of
view.
6

7. This
presentaNon
is
about
ideas
published
by
Kent
Beck
7

8. • Creator
of
Extreme
Programming
• Credited
with
having
developed
or
'rediscovered'
TDD
• One
of
the
signatories
of
the
Agile
Manifesto
• Pioneered
Design
Pa`erns
• Popularised
Class
Responsibility
CollaboraNon
Cards
• Created
the
JUnit
framework
with
Erich
Gamma
• Pioneered
the
commercial
applicaNon
of
Smalltalk
8

9. This
presentaNon
is
about
a
specific
point
of
view
on
how
to
organise
program
logic
using
methods
9

10. At
the
heart
of
this
viewpoint
are
a
handful
of
simple
pa`erns
10

11. Kent
Beck
once
said
that
some
of
his
best
pa`erns
are
those
that
he
thought
someone
would
laugh
at
him
for
wriNng.
11

12. This
is
the
kind
of
pa`ern
we
are
going
to
look
at
So
although
at
Nmes
you
may
find
it
hard
not
to
laugh
at
the
simplicity
of
the
pa`erns
SIMPLE
<>
EASY
It
is
not
necessarily
easy/trivial
to
apply
them
I
think
there
is
value
in
being
aware
of
the
pa`erns
when
programming
Also,
the
message
of
this
presentaNon
is
not
just
the
pa`erns
per
se
but
also
the
wider
narraNve
around
them
12

13. Kent
Beck’s
books
in
which
he
describes
the
pa`erns
13

14. The
two
books
cover
similar
ground
But
they
are
quite
different,
and
in
some
ways
they
complement
each
other
IP
is
higher
level
than
SBPP
more
philosophical
not
so
pracNcal
–
very
li`le
code
in
it
Although
I’ll
be
concentraNng
on
SBPP,
there
will
be
a
couple
of
excepNons,
e.g.
right
now:
I
want
to
tell
you
about
Kent
Beck’s
mo#va#on
for
the
pa`erns
(chapter
4
of
ImplementaNon
Pa`erns)
14

15. In
the
bibliography
of
ImplementaNon
Pa`erns,
we
find:
Edward
Yourdon
and
Larry
ConstanNne,
Structured
Design:
Fundamentals
of
a
Discipline
of
Computer
Program
and
Systems
Design,
PrenNce
Hall,
1979.
ISBN
0138544719.
This
book
presents
the
equivalent
of
the
laws
of
physics
for
so4ware
design
15

16. Beck
says
that
30
years
ago
Yourdon
and
ConstanNne
idenNfied
Economics
as
the
underlying
driver
of
so4ware
design
16

17. Sonware
should
be
designed
to
reduce
its
overall
cost
17

18. COSTtotal
=
COSTdevelop
+
COSTmaintain
The
cost
of
maintenance
is
much
higher
than
the
iniNal
cost
of
development
18

19. Maintenance
is
expensive
because
understanding
exisNng
code
is
Nme-­‐consuming
and
error-­‐prone
19

20. Making
changes
is
generally
easy
once
you
know
what
needs
changing
20

21. COSTmaintain
=
COSTunderstand
+
COSTchange+
COSTtest+
COSTdeploy
Learning
what
the
code
does
is
the
expensive
part
21

22. One
strategy
for
reducing
overall
cost
is
to
invest
more
in
iniNal
development
in
hope
of
reducing
or
eliminaNng
the
need
for
change
22

23. Such
efforts
have
generally
failed
23

24. Beck’s
strategy
for
reducing
overall
costs
is
to
ask
all
programmers
to
address
the
cost
of
understanding
code
during
the
maintenance
phase,
by
communicaNng
programmer
to
programmer
24

25. The
immediate
benefits
of
clear
code
are
fewer
defect,
easier
sharing
of
code,
and
smoother
development
25

26. 1997
–
Smalltalk
Best
PracNce
Pa`erns
This
book
is
about
the
simple
things
experienced,
successful
Smalltalkers
do
that
beginners
don’t
In
a
sense,
it’s
a
style
guide
It
covers
the
daily
tac#cs
of
programming:
How
do
you
choose
names
for
objects,
variables
and
methods?
How
do
you
break
logic
into
methods?
How
do
you
communicate
most
clearly
through
your
code?
26

27. The
advice
is
broken
into
92
pa`erns
Each
pa`ern
presents:
A
recurring
daily
programming
problem
The
tradeoffs
that
affect
the
soluNon
to
the
problem;
and
A
concrete
recipe
to
crate
a
soluNon
for
the
problem
The
pa`erns
don’t
stand
in
isolaNon
They
form
a
system
or
language
27

28. That’s
a
lot
of
pa`erns
28

29. But
Don’t
worry:
we
are
only
going
to
look
at
4
These
are
Fundamental
–
key
to
achieving
good
style
Interrelated
–
they
form
their
own
subsystem
Very
simply
stated
–
but
have
far
reaching
effects
29

30. 30

31. Some
things
are
hard
to
define
Faced
with
the
prospect
of
defining
the
term
‘obscenity’,
a
US
Supreme
Court
JusNce
once
said:
“I
know
it
when
I
see
it,
and
the
moNon
picture
involved
in
this
case
is
not
that”.
Wikipedia
says:
The
phrase
"I
know
it
when
I
see
it"
is
a
colloquial
expression
by
which
a
speaker
a`empts
to
categorize
an
observable
fact
or
event,
although
the
category
is
subjecNve
or
lacks
clearly
defined
parameters.
Here
is
a
book
on
Quality
whose
Ntle
uses
the
expression
in
its
Ntle.
31

32. Beck
says
Good
Programming
Style
is
one
of
those
things
that
everyone
knows
when
they
see
it,
but
is
very
hard
to
ar#culate
precisely.
32

33. He
says
“There
are
a
few
things
I
look
for
that
are
good
predictors
of
whether
a
project
is
in
good
shape.
These
are
also
proper#es
I
strive
for
in
my
code.”
33

34. Once
and
only
once
(OAOO)
If
I
only
have
one
minute
to
describe
good
style,
I
reduce
it
to
a
simple
rule:
In
a
program
wri`en
with
good
style,
everything
is
said
once
and
only
once.
This
isn't
much
help
in
creaNng
good
code,
but
it's
a
darned
good
analyNc
tool.
34

35. If
I
see
several
methods
with
the
same
logic,
several
objects
with
the
same
methods,
or
several
systems
with
similar
objects,
I
know
this
rule
isn't
saNsfied.
This
leads
us
to
the
second
property…
35

36. Lots
of
li`le
pieces
Good
code
invariably
has
small
methods
and
small
objects.
36

37. Only
by
factoring
the
system
into
many
small
pieces
of
state
and
funcNon
can
you
hope
to
saNsfy
the
"once
and
only
once"
rule.
37

38. I
get
lots
of
resistance
to
this
idea,
especially
from
experienced
developers,
but
no
one
thing
I
do
to
systems
provides
as
much
help
as
breaking
it
into
more
pieces.
When
you
are
doing
this,
however,
you
must
always
be
certain
that
you
communicate
the
big
picture
effecNvely.
38

39. OAOO
depends
on
Lots
of
Li`le
Pieces
39

40. Good
style
leads
to
easily
replaceable
objects.
40

41. In
a
really
good
system,
every
Nme
the
user
says
"I
want
to
do
this
radically
different
thing,"
the
developer
says,
"Oh,
I'll
have
to
make
a
new
kind
of
X
and
plug
it
in."
When
you
can
extend
a
system
solely
by
adding
new
objects
without
modifying
any
exisNng
objects,
then
you
have
a
system
that
is
flexible
and
cheap
to
maintain.
41

42. It
seems
to
me
Beck
here
is
referring
to
Bertrand
Meyer’s
“Open
Closed
Principle”
42

43. You
can't
do
this
if
you
don't
have
lots
of
liDle
pieces.
43

44. One
more
indicator/predictor
depending
on
Lots
of
Li`le
Pieces
44

45. Moving
Objects
Another
property
of
systems
with
good
style
is
that
their
objects
can
be
easily
moved
to
new
contexts.
45

46. You
should
be
able
to
say.
"This
object
in
this
system
does
the
same
job
in
that
system.
...
Then,
if
you
have
a
system
built
with
lots
of
liDle
pieces,
you
will
be
able
to
make
the
necessary
modificaNons
and
generalizaNons
fairly
easily.
46

47. One
more
indicator/predictor
depending
on
Lots
of
Li`le
Pieces
47

48. Don't
put
two
rates
of
change
together.
• Don't
have
part
of
a
method
that
changes
in
every
subclass
with
parts
that
don't
change.
• Don't
have
some
instance
variables
whose
value
changes
every
second
in
the
same
object
with
instance
variables
whose
values
change
once
a
month.
• Don't
have
a
collecNon
where
some
elements
are
added
and
removed
every
second
and
some
elements
are
added
and
removed
once
a
month.
• Don't
have
code
in
an
object
that
has
to
change
for
every
piece
of
hardware,
and
code
that
has
to
change
for
every
operaNng
system.
• How
do
you
avoid
this
problem?
You
got
it,
lots
of
li`le
pieces.
48

49. The
5
(1
+
4)
properNes
(predictors
)
of
systems
wri`en
in
good
style
(of
projects
in
good
shape)
49

50. For
those
familiar
with
Fowler’s
‘Refactoring’,
it
is
not
IMHO
a
coincidence
what
the
first
three
smells
are
in
the
book’s
sNnk
parade
(see
next
slide).
50

51. The
book
was
published
two
years
aner
SBPP
and
Kent
Beck
was
one
of
the
collaborators
on
the
‘smells’
topic.
51

52. Methods
are
important
to
the
system
because
they
are
how
work
gets
done
in
Smalltalk.
52

53. Just
as
important,
methods
are
the
way
you
communicate
to
readers
how
you
intended
for
work
to
get
done.
53

54. You
must
write
your
methods
with
both
of
these
audiences
in
mind.
Readers
of
the
code,
who
are
more
interested
in
the
‘what’,
and
the
computer,
which
is
interested
in
the
‘how’.
54

55. Methods
must
do
the
work
they
are
supposed
to
do
but
they
must
also
communicate
the
intent
of
the
work
to
be
done.
55

56. It
is
important
to
disNnguish
between
INTENTION
(WHAT)
and
HOW
(IMPLEMENTATION)
That
is
the
Chinese
ideogram
for
Intent/IntenNon
56

57. Methods
decompose
the
funcNon
of
your
program
into
easily
diges#ble
chunks.
57

58. Carefully
breaking
a
computa#on
into
methods
and
carefully
choosing
their
names
58

59. communicates
more
about
your
inten#ons
to
a
reader
than
any
other
programming
decision,
besides
class
naming.
59

60. So
one
of
the
Benefits
of
Methods
is
CommunicaNon
60

61. Another
benefit
of
methods
is
flexibility
Methods
are
the
granularity
of
overriding.
A
well
factored
superclass
can
always
be
specialized
by
overriding
a
single
method,
without
having
to
copy
part
of
the
superclass
code
into
the
subclass.
61

62. Recap:
two
benefits
of
methods
are
communicaNon
and
flexibility
62

63. But
Methods
don't
come
for
free.
Their
cost
is
management
overhead.
63

64. Managing
all
those
bits
and
pieces
of
code
-­‐
wriNng
them
in
the
first
place,
naming
them,
remembering,
rediscovering,
and
communicaNng
how
they
all
fit
together
64

65. This
mgmt
overhead
takes
Nme.
If
there
is
no
benefit
to
be
gained,
bigger
methods
would
be
beDer
than
small
because
of
the
reduced
management
overhead.
65

66. Methods
cost
in
performance
as
well.
66

67. Each
method
invocaNon
takes
precious
computer
cycles.
67

68. The
trick
to
geIng
good
performance
is
using
methods
as
a
lever
to
make
your
performance
measurement
and
tuning
more
effecNve.
68

69. In
my
experience,
beDer
factored
code,
with
lots
of
small
methods,
both
allows
more
accurate
and
concise
performance
measurement
(because
there
aren't
li`le
snippets
of
code
duplicated
all
over)
and
provides
leverage
for
tuning
(through
techniques
like
Caching
Instance
Variable).
69

70. From
ImplementaNon
Pa`erns:
• As
I
was
wriNng
this
I
wrote
a
li`le
benchmark
program
that
compared
a
million
loop
itera#ons
with
a
million
messages
70

71. • The
overhead
was
20-­‐30%
on
average,
not
enough
to
affect
the
performance
of
most
programs.
71

72. The
combinaNon
of
faster
CPUs
and
the
strongly
localized
nature
of
performance
bo`lenecks
72

73. makes
code
performance
an
issue
best
le4
un#l
you
can
gather
sta#s#cs
from
realis#c
data
sets
73

74. Overall,
the
goal
of
breaking
your
program
into
methods
is
to:
• communicate
your
intent
clearly
with
your
reader
• provide
for
future
flexibility
• set
yourself
up
for
effecNve
performance
tuning
where
necessary
74

75. Let’s
look
at
the
pa`erns
75

76. Decomposing
Message
How
do
you
invoke
parts
of
a
computaNon?
76

77. A
method
is
ge{ng
too
big
and
you
need
to
break
it
into
parts
so
you
can
understand
it
be`er
77

78.
AlternaNvely,
you
may
have
noNced
that
two
or
more
methods
have
similar
parts…
78

79. …
and
you’d
like
to
put
the
parts
in
a
single
method
79

80. How
do
you
invoke
parts
of
a
computaNon?
Send
several
messages
to
‘self’
80

81. To
control
an
acNvity,
the
controller
sends
itself
a
sequence
of
messages
This
is
so
simple.
Why
am
I
telling
you
this?
81

82. Because
Smalltalk
code
reveals
a
much
more
aggressive
aItude
towards
decomposing
code
than
other
languages
82

83. Most
style
guides
say
“Keep
the
code
for
a
rouNne
on
one
page”.
Most
good
Smalltalk
methods
fit
into
a
few
lines
83

84. Certainly
(always)
less
than
10,
and
o4en
(some#mes)
3
or
4
84

85. (to
be
fair)
partly
this
is
possible
because
the
abstracNons
Smalltalk
provides
are
higher
level
than
what
other
languages
provide
85

86. The
other
reason
I
am
telling
you
about
decomposing
message
is
because
it
has
a
‘forward’
secNon
that
binds
together
the
other
three
pa`erns
we
are
going
to
look
at.
Once
you
have
decided
to
decompose
a
method,
you:
• Use
Composed
Method
to
break
the
method
into
pieces
• Make
each
method
an
IntenNon
Revealing
Method
• Use
Explaining
Message
to
communicate
intent
separate
from
implementa#on
86

87. Ok,
so
we
have
seen
the
‘Decomposing
Message’
pa`ern.
Now
we
are
going
to
look
at
the
Composed
Method
pa`ern.
87

88. As
an
aside,
in
this
interview
(on
InfoQ)
about
ImplementaNon
Pa`erns,
when
Beck
is
asked
which
are
the
central
pa`erns
of
the
book
he
says
that
the
canonical
one
is
composed
method.
88

89. Composed
Method
How
do
you
divide
a
program
into
methods?
89

90. Programs
need
to
do
more
than
just
instruct
a
computer,
they
need
to
communicate
to
people
as
well.
90

91. How
your
program
is
broken
into
methods
(as
well
as
how
big
those
methods
are)…
91

92. …this
one
of
the
most
important
decisions
you
will
make
as
you
refine
your
code
so
that
it
communicates
as
clearly
as
possible.
92

93. How
do
you
divide
a
program
into
methods?
• Divide
your
program
into
methods
that
perform
one
idenNfiable
task
• Keep
all
of
the
operaNons
in
a
method
at
the
same
level
of
abstracNon
• This
will
naturally
result
in
programs
with
many
small
methods,
each
a
few
lines
long
93

94. Example
of
composed
method.
Yes,
it
is
exactly
the
same
example
as
for
Decomposing
Message,
but
that
makes
sense
if
you
think
about
it.
94

95. 1.
Divide
your
program
into
methods
that
perform
one
iden#fiable
task
Easier
said
than
done.
In
Clean
Code,
Uncle
Bob
uses
an
alternaNve
expression
of
‘one
idenNfiable
task’:
FUNCTIONS
SHOULD
DO
ONE
THING.
THEY
SHOULD
DO
IT
WELL.
THEY
SHOULD
DO
IT
ONLY
He
says
“the
problem
with
that
statement
is
that
it
is
hard
to
know
what
“one
thing”
is”
In
another
presentaNon
we’ll
look
at
why
he
says
that.
For
the
rest
of
this
presentaNon
we’ll
just
pretend
that
it
is
simple
to
determine
if
a
method
performs
one
idenNfiable
task.
95

96. 2)
Keep
all
of
the
opera#ons
in
a
method
at
the
same
level
of
abstrac#on
Glenn
Vanderburg
(h`ps://twi`er.com/glv)
named
this
SLAP:
Single
Level
of
AbstracNon
Principle
The
following
method
(from
ImplementaNon
Pa`erns)
is
jarring
to
the
reader:
void
compute()
{
input();
flags|=
0x0080;
output();
}
You
can’t
help
asking
yourself:
What
is
that
bit
twiddling
in
there?
What
does
it
mean?
Code
is
easy
to
understand
when
it
flows.
96

97. 3)
This
will
naturally
result
in
programs
with
many
small
methods,
each
a
few
lines
long
We
have
looked
at
the
advantages
that
result
from
lots
of
li`le
pieces.
It
is
not
just
simple
minded
performance
tuning
that
can
lead
one
to
believe
that
larger
methods
are
be`er.
97

98. Following
the
flow
of
control
in
programs
with
many
small
methods
can
be
difficult
Novice
Smalltalk
programmers
onen
complain
that
they
can’t
figure
out
where
any
“real”
work
is
ge{ng
done.
This
suggests
to
them
that
large
methods
are
best.
98

99. But
with
experience
they
understand
that
well
chosen
names
let
you
correctly
assume
the
meaning
of
invoked
code.
99

100. The
most
compelling
reason
for
keeping
methods
small
is
the
opportunity
to
communicate
with
intenNon
revealing
method
names.
Which
is
the
name
of
the
next
pa`ern
we
are
going
to
look
at.
100

101. So,
we
just
looked
at
Composed
Method.
Now
we
are
going
to
look
at
IntenNon
Revealing
Method
Name
101

102. IntenNon
Revealing
Method
What
do
you
name
a
method?
102

103. You
have
two
opNons
in
naming
methods
The
first
is
to
name
the
method
aner
how
it
accomplishes
its
task.
Thus,
searching
methods
would
be
called:
Array<<linearSearchFor
Set<<hashedSearchFor
Btree<<treeSearchFor
103

104. The
most
important
argument
against
this
style
of
naming
is
that
it
doesn’t
communicate
well.
It
is
not
a
developer’s
goal
to
blurt
out
everything
they
know
about
their
program
as
soon
as
possible.
Unless
the
implementaNon
strategy
is
relevant
to
users,
leave
it
out
of
the
name
The
curious
can
look
at
the
body
of
the
method
to
see
how
it
is
implemented
104

105. The
second
opNon
is
to
name
a
method
a4er
what
it
is
supposed
to
accomplish,
and
leave
“how”
to
the
various
method
bodies
This
is
hard
work,
especially
when
you
only
have
a
single
implementaNon
Your
mind
is
filled
with
how
you
are
about
to
accomplish
the
task,
so
it
is
natural
that
the
name
follow
“how”
105

106. The
effort
of
moving
the
name
of
methods
from
“how”
to
“what”
is
worth
it,
both
in
the
short
term
and
the
long
term
The
resulNng
code
will
be
easier
to
read
and
understand
106

107. What
do
you
name
a
method?
Name
methods
aner
what
they
accomplish
(NOT
how
they
accomplish
it)
107

108. Applying
this
to
our
example,
we
would
name
all
three
methods
searchFor
CollecNons>>searchFor
Really
though,
searching
is
a
way
of
implemenNng
a
more
general
concept:
inclusion
Trying
to
name
the
message
aner
this
more
general
“what”
leads
us
to
CollecNons>>includes
108

109. The
forward
secNon
of
this
pa`ern
says:
Once
you
name
a
method,
write
its
body
using
Composed
Method
As
onen
with
pa`erns,
they
refer
to
each
other.
This
makes
it
easier
to
express
them,
but
can
make
it
harder
to
understand
them
at
first.
109

110. OK,
so
we
have
looked
at
IntenNon
Revealing
Method
Name
And
we
no
look
at
the
last
pa`ern:
Explaining
Message
110

111. How
do
you
communicate
your
intent
when
the
implementaNon
is
simple?
111

112. Probably
the
most
frustraNng
part
of
learning
Smalltalk
You
see
a
message
like
highlight
and
think:
this
has
to
be
something
interesNng
ParagraphEditor>>highlight:aRectangle
self
reverse:aRectangle
What
is
going
on?
Communica#on.
Most
importantly,
one
line
methods
are
there
to
communicate.
112

113. How
do
you
communicate
your
intent
when
the
implementaNon
is
simple?
• Send
a
message
to
“self”.
• Name
the
message
so
that
it
communicates
what
is
to
be
done
rather
than
how
it
is
to
be
done.
• Code
a
simple
method
for
the
message.
113

114. Explaining
Messages
are
the
most
extreme
case
of
wri#ng
for
readers
instead
of
the
computer
Two
examples:
CollecNon>>isEmpty
^self
size
=
0
Number>>reciprocal
^1
/
self
Explaining
Message
allows
us
to
separate
intenNon
(the
what)
from
implementaNon
(the
how):
the
method
names
tell
us
what,
and
the
method
bodies
tell
us
how.
114

115. An
example
from
Fowler’s
Refactoring.
The
methods
in
blue
that
we
have
extracted
are
Explaining
Messages.
TO
DO:
menNon
Fowler’s
concept
of
semanNc
distance
between
the
name
of
a
method
and
its
body.
115

116. OK,
so
we
have
no
looked
at
all
four
pa`erns.
So
what
next?
116

117. Beck’s
example
of
composed
method
wasn’t
great
(IMHO)…
117

118. …so
I
want
to
look
at
a
be`er
example
in
Kerievsky’s
“Refactoring
To
Pa`erns”
118

119. Kerievsky
is
the
head
of
Industrial
Logic,
which
runs
intersNng
course
like
the
ones
above.
They
know
their
stuff.
119

120. It
takes
some
#me
to
understand
what
the
method
does
But
if
we
apply
Composed
Method….
The
method
now
contains
only
five
lines
of
code.
I
can
rapidly
understand
what
the
method
does
in
ONE
SECOND.
This
is
a
typical
result
of
applying
Composed
Method.
120

121. Actually
we
can
look
at
an
intermediate
step
for
a
good
example
of
an
explaining
message.
In
the
code
above,
the
last
line
is
not
at
the
same
level
of
detail
as
the
rest
of
the
method.
We
are
violaNng
the
SLAP.
We
fix
this
by
applying
Explaining
Message,
i.e.
we
extract
the
offending
line
into
its
own
method.
We
are
now
conforming
to
the
SLAP.
121

122.
Composed
Method
A
small,
simple
method
that
you
can
understand
in
seconds
I
like
Kerievsky’s
‘speed’
angle
on
the
composed
pa`ern:
it
is
so
easy
to
understand
that
it
can
be
done
very
quickly.
122

123. The
same
angle
again:
You
apply
the
pa`ern
when
you
can’t
rapidly
understand
a
method.
We
just
saw
his
example
of
this
a
couple
of
slides
ago.
123

124. IMHO
Beck
and
Kerievsky
both
refrain
from
EXPLICITLY
staNng
one
aspect
o
fwhy
a
composed
method
is
so
easy
to
quickly
read
and
understand
.
They
both
say
(kerievsky
verbaNm,
and
Beck
more
implicitly):
A
Composed
Method's
name
communicates
what
it
does,
while
its
body
communicates
how
it
does
what
it
does.
124

125. What
they
don’t
explicitly
say
is
that…
Although
it
is
true
that
Composed
Method
tells
the
reader
‘how’
it
does
what
it
does
(which
is
usually
what
slows
down
readers)…
it
consists
purely
or
primarily
of
calls
to
methods
with
inten#on
revealing
names…
and
so
it
actually
reveals
only
a
liDle
bit
of
the
‘how’,
hiding
the
rest
behind
said
calls.
125

126. So
composed
method
reveals
implementaNon
(how)
only
a
li`le
bit
at
a
Nme
(which
is
what
makes
reading
and
understanding
composed
methods
so
easy/quick).
I
found
this
fact
menNoned
in
Alan
Shalloway’s
(et
al.)
‘EssenNal
Skills
For
The
Agile
Developer’.
The
four
pa`erns
we
have
looked
at
are
part
of
what
in
Extreme
Programming
is
called
IntenNonal
Programming.
The
key
organizing
principle
in
(composed)
methods
wri`en
in
the
IntenNonal
Programming
style
is
that
their
body
contains
all
the
steps
(the
what),
but
very
li`le
of
the
actual
implementaNon
(the
how).
What
IntenNonal
Programming
(and
composed
method)
do
is
allow
us
to
separate
the
process
by
which
something
is
done
from
the
actual
accomplishing
of
the
thing.
126

127. And
here
is
a
good
example
of
composed
method
from
the
book.
We
can
clearly
see
the
focus
on
the
WHAT,
and
the
minimal
amount
of
HOW
that
the
method
reveals:
this
is
what
makes
the
method
easy
to
quickly
read
and
understand
127

128. Back
to
‘Refactoring
to
Pa`erns’,
to
have
a
quick
look
at
a
few
more
of
Kerievsky’s
interesNng
angles
on
composed
method.
128

129. “Do
you
write
lots
of
composed
methods?
I
like
to
think
I
do,
but
I
onen
find
that
I
don't,
at
first.
So
I
have
to
go
back
and
refactor
to
this
paDern.
“
This
is
not
surprising
since
the
thesis
of
the
book
is
that
design
pa`erns
are
not
something
you
apply
up
front,
but
something
that
you
refactor
towards
when
you
find
the
need.
When
code
contains
lots
of
composed
methods
then
it
tends
to
be
easy
to
use
read
and
extend.
129

130. Remember
earlier
when
we
saw
Beck’s
thoughts
on
the
typical
length
of
good
Smalltalk
methods?
Always
less
than
10
lines.
SomeNmes
3
or
4
lines
Here
we
see
Kerievsky’s
take
on
this:
rarely
more
than
10
lines.
Usually
about
5.
Largely
in
line
with
Beck
IMHO
when
you
consider
that
Kerievsky
is
dealing
with
Java,
whose
abstracNons
are
lower
level
than
Smalltalk’s
130

131. I’ll
conclude
this
look
at
‘Refactoring
to
Pa`erns’
with
this
thought
of
Kerievsky’s:
When
you
add
up
all
the
Nme
you
and
your
team
spend
trying
to
understand
a
system's
code,
you
can
just
imagine
how
much
more
efficient
and
effecNve
you'll
be
if
the
system
is
composed
of
many
Composed
Methods.
131

132. I
think
I
can
safely
say
that
so
far
I
have
engaged
your
visual
channel.
To
improve
retenNon,
allow
me
to
sNmulate
your
auditory
channel
by
playing
part
of
a
poem
on
Composed
Method,
composed
by
Tim
Berglund
(h`ps://twi`er.com/tlberglund)
Play
the
following
from
minute
3
onwards:
http://www.youtube.com/watch?v=3QbheQitF74
132

133. 133

134. 134

135. 135