1
00:00:00,040 --> 00:00:03,720
Welcome back to the Deep dive. 
Today we're not just talking 

2
00:00:03,720 --> 00:00:07,160
about code cleanup in general. 
We're doing a really focused 

3
00:00:07,160 --> 00:00:10,960
exploration, a surgical strike 
you might say, into two core 

4
00:00:10,960 --> 00:00:14,640
refactoring techniques in line 
method and move methyl. 

5
00:00:14,640 --> 00:00:16,800
That's right. 
And we're using Marco Tulio 

6
00:00:16,800 --> 00:00:20,760
Valente's Software Engineering a
Modern approach as our guide. 

7
00:00:20,760 --> 00:00:25,440
It's all about understanding how
these, well, seemingly small 

8
00:00:25,440 --> 00:00:28,880
adjustments are actually 
fundamental to building robust, 

9
00:00:28,880 --> 00:00:30,680
healthy software. 
Absolutely. 

10
00:00:30,680 --> 00:00:32,800
So refactoring just a level set 
quickly. 

11
00:00:32,800 --> 00:00:35,320
It's about improving the inside 
without changing the outside. 

12
00:00:35,320 --> 00:00:37,680
Precisely improving the design, 
making it cleaner, more 

13
00:00:37,680 --> 00:00:41,680
maintainable, easier to work 
with down the line, all without 

14
00:00:41,680 --> 00:00:43,840
altering what the software 
actually does for the user. 

15
00:00:44,160 --> 00:00:47,440
And our mission today 
specifically is to unpack inline

16
00:00:47,440 --> 00:00:49,480
method and move method. 
Why do they matter so much? 

17
00:00:49,840 --> 00:00:52,440
OK, let's stop straight in then 
with inline method. 

18
00:00:52,480 --> 00:00:55,240
Now many developers I think are 
familiar with extract method 

19
00:00:55,240 --> 00:00:57,200
pulling code out into a new 
function. 

20
00:00:57,200 --> 00:00:59,640
Inline method is well, the 
opposite journey isn't it? 

21
00:00:59,640 --> 00:01:01,240
Putting code back. 
Exactly. 

22
00:01:01,240 --> 00:01:04,280
It's about taking that separate 
methods code and folding it 

23
00:01:04,280 --> 00:01:06,280
directly into wherever it was 
called from. 

24
00:01:06,320 --> 00:01:07,880
So. 
Why would you do that? 

25
00:01:07,880 --> 00:01:11,360
It feels a bit counterintuitive,
like you're undoing organization

26
00:01:11,880 --> 00:01:16,520
when is less actually more here.
That's the key question, and 

27
00:01:16,520 --> 00:01:18,800
Valente points to very specific 
situations. 

28
00:01:19,400 --> 00:01:22,840
Primarily it's beneficial when a
methods body is incredibly 

29
00:01:22,840 --> 00:01:26,440
small, like maybe just one or 
two lines, sometimes even just a

30
00:01:26,440 --> 00:01:28,240
single expression. 
OK, really tiny. 

31
00:01:28,280 --> 00:01:31,360
Yes, tiny. 
And crucially, it's also when 

32
00:01:31,360 --> 00:01:34,360
that method isn't called from 
many different places, maybe 

33
00:01:34,360 --> 00:01:38,240
just once or perhaps a couple of
times in very close proximity. 

34
00:01:38,840 --> 00:01:41,040
So it's not providing much reuse
benefit anyway. 

35
00:01:41,040 --> 00:01:43,440
Exactly. 
In those cases, the typical 

36
00:01:43,440 --> 00:01:46,400
advantages of a separate method,
you know, abstraction, 

37
00:01:46,400 --> 00:01:47,840
modularity. 
They're minimal. 

38
00:01:48,240 --> 00:01:51,800
Sometimes such a tiny, rarely 
used method can even add 

39
00:01:51,880 --> 00:01:54,640
unnecessary complexity, a little
bit of indirection that just 

40
00:01:54,640 --> 00:01:56,800
makes you jump around the code 
for no real game. 

41
00:01:56,800 --> 00:02:00,120
Like cognitive overhead, having 
to keep track of too many tiny 

42
00:02:00,120 --> 00:02:01,560
pieces. 
Precisely. 

43
00:02:02,360 --> 00:02:05,360
It can fragment the logic. 
You're trying to follow a 

44
00:02:05,360 --> 00:02:08,360
process and suddenly you have to
navigate a way to understand 

45
00:02:08,360 --> 00:02:11,320
this one tiny step before coming
back. 

46
00:02:11,560 --> 00:02:15,040
Inline method helps consolidate 
that makes the main flow 

47
00:02:15,040 --> 00:02:18,160
clearer. 
So the practical step is you 

48
00:02:18,160 --> 00:02:21,400
find these tiny, maybe single 
use methods, you remove the 

49
00:02:21,400 --> 00:02:25,280
method definition itself and you
just paste it's, well, one or 

50
00:02:25,280 --> 00:02:28,320
two lines of code directly into 
the spot or spots where it was 

51
00:02:28,320 --> 00:02:31,120
being called the call sites. 
That's the essence of it, 

52
00:02:31,320 --> 00:02:34,160
cleaning up that sort of micro 
clutter or maybe premature 

53
00:02:34,160 --> 00:02:36,680
abstraction. 
Makes the code feel more direct.

54
00:02:36,680 --> 00:02:40,400
Yes, but it's worth noting, as 
Valente highlights, inline 

55
00:02:40,400 --> 00:02:43,760
method is generally less common,
maybe less impactful overall 

56
00:02:44,000 --> 00:02:45,640
than its counterpart extract 
method. 

57
00:02:45,720 --> 00:02:47,760
Which makes sense. 
Usually the drive is to 

58
00:02:47,960 --> 00:02:51,200
breakdown complexity, not 
consolidate simplicity, right? 

59
00:02:51,400 --> 00:02:54,760
But it's still a valuable tool 
for tidying up when abstraction 

60
00:02:54,760 --> 00:02:57,520
maybe went a bit too far or 
wasn't really needed in the 1st 

61
00:02:57,520 --> 00:02:58,000
place. 
The. 

62
00:02:58,000 --> 00:03:00,000
Source had a good clear example,
didn't it? 

63
00:03:00,000 --> 00:03:01,920
Something about writing to a 
file? 

64
00:03:01,920 --> 00:03:05,360
It did a method called write 
content to file sounds 

65
00:03:05,360 --> 00:03:08,840
important, but its entire body 
was just a single line of code. 

66
00:03:09,040 --> 00:03:12,480
Just one line. 
Just one, and critically, it was

67
00:03:12,480 --> 00:03:15,520
only ever called from one other 
place, a method called write. 

68
00:03:16,160 --> 00:03:19,000
So 0 reuse minimal abstraction 
value. 

69
00:03:19,000 --> 00:03:21,040
Pretty much. 
So the developers decided OK, 

70
00:03:21,040 --> 00:03:23,000
this extra method isn't pulling 
its weight. 

71
00:03:23,360 --> 00:03:26,440
They removed right content to 
file and just put that single 

72
00:03:26,440 --> 00:03:28,560
line of code directly into the 
right method. 

73
00:03:28,640 --> 00:03:32,040
And the outcome? 
Simpler code, less indirection, 

74
00:03:32,440 --> 00:03:35,000
easier to read the right 
methods, logic straight through,

75
00:03:35,360 --> 00:03:38,280
and crucially, no change at all 
to the external behavior. 

76
00:03:38,360 --> 00:03:41,840
OK, so that's inline method 
neatening things up by removing 

77
00:03:41,840 --> 00:03:45,640
very small underused functions. 
But sometimes the issue isn't 

78
00:03:45,640 --> 00:03:48,880
that a function is too small, 
but that it's, well, in the 

79
00:03:48,880 --> 00:03:52,400
wrong house entirely. 
And that brings us to move 

80
00:03:52,400 --> 00:03:54,120
method. 
This one feels like it has 

81
00:03:54,120 --> 00:03:55,880
bigger architectural 
implication. 

82
00:03:55,880 --> 00:03:58,800
Oh definitely. 
Move method is often a much more

83
00:03:58,800 --> 00:04:01,880
significant refactoring. 
It's about getting functionality

84
00:04:01,880 --> 00:04:03,840
to reside in the most logical 
place. 

85
00:04:04,000 --> 00:04:06,080
So what's the core problem at 
solving? 

86
00:04:06,080 --> 00:04:09,320
Why would a method end up in the
wrong class to begin with? 

87
00:04:09,560 --> 00:04:11,800
It happens often during 
development or evolution. 

88
00:04:12,240 --> 00:04:15,280
You might find a method sitting 
in, let's call it Class A, but 

89
00:04:15,960 --> 00:04:19,600
when you look closely, that 
method uses features, data, 

90
00:04:20,079 --> 00:04:23,320
other methods from Class B much 
more heavily than it uses 

91
00:04:23,320 --> 00:04:26,920
anything from its own Class A. 
So it's real center of gravity 

92
00:04:26,920 --> 00:04:28,360
is somewhere else. 
Exactly. 

93
00:04:28,360 --> 00:04:31,440
It's more interested in Class 
B's business than Class A's. 

94
00:04:32,280 --> 00:04:35,880
It feels misplaced, like keeping
your gardening tools in the 

95
00:04:35,880 --> 00:04:38,320
bedroom closet. 
They work, but it's not where 

96
00:04:38,320 --> 00:04:39,320
they belong. 
Right. 

97
00:04:39,440 --> 00:04:41,360
And moving them has real 
benefits. 

98
00:04:41,360 --> 00:04:44,080
Huge benefits. 
According to the source, moving 

99
00:04:44,080 --> 00:04:47,600
the method to Class B where it 
belongs does 2 critical things. 

100
00:04:47,600 --> 00:04:51,200
First, it significantly improves
the cohesion of Class A Class A 

101
00:04:51,200 --> 00:04:54,360
becomes more focused on its core
responsibility because unrelated

102
00:04:54,360 --> 00:04:55,960
logic has been moved out. 
Makes sense? 

103
00:04:56,000 --> 00:04:58,480
Tighter focus. 
Second, it reduces the coupling 

104
00:04:58,480 --> 00:05:01,520
between Class A and Class B. 
Because Class A no longer needs 

105
00:05:01,520 --> 00:05:04,320
to host this method that heavily
depends on B, their 

106
00:05:04,320 --> 00:05:07,040
interdependence decreases. 
Less tangled up, which means 

107
00:05:07,200 --> 00:05:10,520
changes in B are less likely to 
break A and vice versa. 

108
00:05:10,680 --> 00:05:13,360
Precisely. 
It makes both classes easier to 

109
00:05:13,360 --> 00:05:17,000
understand, easier to modify 
independently, and easier to 

110
00:05:17,000 --> 00:05:19,520
test. 
That's vital for long term 

111
00:05:19,520 --> 00:05:21,800
maintainability. 
So this sounds like it really 

112
00:05:21,800 --> 00:05:24,400
impacts the overall system 
modularity. 

113
00:05:24,400 --> 00:05:27,720
Getting methods into the right 
classes strengthens those 

114
00:05:27,720 --> 00:05:29,400
boundaries. 
It absolutely does. 

115
00:05:29,400 --> 00:05:31,760
It's a key technique for 
improving the architectural 

116
00:05:31,760 --> 00:05:35,160
health of a system, ensuring 
responsibilities are clearly 

117
00:05:35,160 --> 00:05:37,200
delineated. 
Valente gives an example. 

118
00:05:37,440 --> 00:05:39,200
I think it was average among 
medians. 

119
00:05:39,200 --> 00:05:41,600
Yes, that was it. 
Right, so this method average 

120
00:05:41,600 --> 00:05:44,680
among medians was initially 
found in a class called platform

121
00:05:44,680 --> 00:05:48,880
test util a utility class. 
Sounds generic, but the method 

122
00:05:48,880 --> 00:05:52,480
itself calculated the average of
medians in an array, A 

123
00:05:52,480 --> 00:05:56,560
mathematical array focused 
operation, and crucially, it had

124
00:05:56,560 --> 00:05:59,240
basically no connection to 
anything else in platform test 

125
00:05:59,240 --> 00:06:01,960
util didn't use its data, didn't
relate to its other utility 

126
00:06:01,960 --> 00:06:04,800
functions, it was just there. 
Kind of an island within the 

127
00:06:04,800 --> 00:06:05,680
class. 
Exactly. 

128
00:06:05,680 --> 00:06:08,280
It felt like it belonged more 
with general array operations, 

129
00:06:08,280 --> 00:06:10,240
so the developers moved it. 
Where did it go? 

130
00:06:10,600 --> 00:06:13,520
They moved it to a different 
class, potentially a new one 

131
00:06:13,800 --> 00:06:17,840
called Array util, whose entire 
purpose was handling array 

132
00:06:17,840 --> 00:06:20,480
manipulations. 
Makes perfect sense putting it 

133
00:06:20,480 --> 00:06:22,440
with its peers, functionally 
speaking. 

134
00:06:22,480 --> 00:06:25,240
Precisely. 
It's now in a class where its 

135
00:06:25,240 --> 00:06:28,160
purpose aligns with the classes 
overall responsibility. 

136
00:06:28,160 --> 00:06:30,720
Yeah, better cohesion, better 
findability. 

137
00:06:30,760 --> 00:06:33,680
OK, but moving a method, 
especially in a big system, 

138
00:06:33,920 --> 00:06:37,120
raises A practical issue. 
What about all the code that was

139
00:06:37,120 --> 00:06:39,160
calling the method in its old 
location? 

140
00:06:39,400 --> 00:06:42,160
You move the method, say from 
Class A to Class B. 

141
00:06:42,440 --> 00:06:45,600
Don't you then have to find and 
update every single call site? 

142
00:06:45,600 --> 00:06:47,840
That sounds risky. 
It can be, yes. 

143
00:06:48,120 --> 00:06:50,880
The ripple effect is a real 
concern, but there are standard 

144
00:06:50,880 --> 00:06:53,720
ways to manage this. 
If the method was static, it's 

145
00:06:53,720 --> 00:06:55,880
often simpler. 
Usually just need to change the 

146
00:06:55,880 --> 00:06:59,720
class name prefix at each call 
site so A method becomes B 

147
00:06:59,720 --> 00:07:01,720
method. 
Compilers help find these. 

148
00:07:01,720 --> 00:07:05,320
OK, static is manageable. 
What about non static methods or

149
00:07:05,320 --> 00:07:08,200
cases where the calling code 
doesn't already have a reference

150
00:07:08,200 --> 00:07:10,640
to an object of Class B? 
That's where it gets more 

151
00:07:10,640 --> 00:07:13,760
complex, but there's a very 
clever common technique 

152
00:07:13,760 --> 00:07:16,160
mentioned in the source, the 
forwarding method. 

153
00:07:16,200 --> 00:07:18,800
Forwarding method, yeah. 
Instead of immediately deleting 

154
00:07:18,800 --> 00:07:21,800
the method from the original 
class, you leave behind a simple

155
00:07:21,800 --> 00:07:24,120
version. 
This version in Class A doesn't 

156
00:07:24,120 --> 00:07:26,880
do the work anymore. 
Its only job is to immediately 

157
00:07:26,880 --> 00:07:29,520
call the method in its new 
location Class B. 

158
00:07:30,440 --> 00:07:32,760
Like a redirect? 
Exactly like a redirect. 

159
00:07:33,080 --> 00:07:37,040
So if a client was calling AF 
and you move F to Class B, you 

160
00:07:37,040 --> 00:07:40,600
can leave a method F and A that 
just does return BF, assuming A 

161
00:07:40,600 --> 00:07:43,160
has a reference to B. 
So the client code doesn't even 

162
00:07:43,160 --> 00:07:45,720
need to know the method moved, 
at least not initially. 

163
00:07:45,720 --> 00:07:47,840
Correct. 
It allows you to make the move 

164
00:07:47,880 --> 00:07:51,960
internally and then update the 
client calls gradually, or 

165
00:07:51,960 --> 00:07:54,760
perhaps only when those clients 
are modified for other reasons. 

166
00:07:55,080 --> 00:07:58,160
It decouples the refactoring 
from the immediate need to 

167
00:07:58,160 --> 00:08:01,480
update all callers. 
Much safer in large systems. 

168
00:08:01,840 --> 00:08:03,560
That's a really pragmatic 
approach. 

169
00:08:03,560 --> 00:08:05,720
Makes a big change much less 
disruptive. 

170
00:08:06,240 --> 00:08:08,240
Now, you mentioned moving 
between classes. 

171
00:08:08,240 --> 00:08:11,640
Are there special kinds of moves
within a class hierarchy, like 

172
00:08:11,640 --> 00:08:13,160
between parent and child 
classes? 

173
00:08:13,280 --> 00:08:16,320
Yes, absolutely. 
Filente covers these two. 

174
00:08:16,720 --> 00:08:19,720
When move method happens within 
an inheritance structure, we 

175
00:08:19,720 --> 00:08:22,920
often use more specific names. 
There's pull up method. 

176
00:08:23,280 --> 00:08:26,280
This is when you move a method 
from a subclass up into its 

177
00:08:26,280 --> 00:08:28,440
superclass. 
OK, why would you do that? 

178
00:08:28,600 --> 00:08:32,640
Usually because the same method 
exists duplicated in several 

179
00:08:32,640 --> 00:08:35,600
sibling subclasses. 
By pulling it up into the common

180
00:08:35,600 --> 00:08:38,159
parent class you eliminate that 
redundancy. 

181
00:08:38,280 --> 00:08:41,080
You have 1 shared implementation
instead of many copies. 

182
00:08:41,559 --> 00:08:43,960
Promotes reuse, simplifies 
maintenance. 

183
00:08:43,960 --> 00:08:46,440
Consolidating shared behavior 
upwards makes sense. 

184
00:08:46,440 --> 00:08:48,360
What's the opposite? 
That would be pushed down 

185
00:08:48,360 --> 00:08:52,120
method, moving a method from a 
superclass down into one or more

186
00:08:52,120 --> 00:08:54,800
of its subclasses. 
And the reason for pushing down?

187
00:08:55,120 --> 00:08:57,800
This is typically done when a 
method in the superclass is 

188
00:08:57,800 --> 00:09:01,600
actually only relevant or used 
by a specific subclass, or maybe

189
00:09:01,600 --> 00:09:02,440
just a few. 
Of them. 

190
00:09:02,440 --> 00:09:04,720
So it doesn't really belong to 
all children, right? 

191
00:09:05,160 --> 00:09:08,320
Pushing it down to only the 
relevant subclasses makes a 

192
00:09:08,320 --> 00:09:11,760
superclass cleaner and more 
general, and clarifies the 

193
00:09:11,760 --> 00:09:13,760
behavior is specific to those 
children. 

194
00:09:14,440 --> 00:09:17,160
It avoids burdening other 
subclasses with irrelevant 

195
00:09:17,160 --> 00:09:19,360
methods. 
So pull up centralizes 

196
00:09:19,360 --> 00:09:23,560
commonality, push down localizes
specificity, both about getting 

197
00:09:23,560 --> 00:09:25,600
behavior to the right level in 
the hierarchy. 

198
00:09:25,600 --> 00:09:27,720
Exactly. 
They're crucial for maintaining 

199
00:09:27,720 --> 00:09:30,920
clean, understandable 
inheritance relationships. 

200
00:09:31,440 --> 00:09:34,280
It's really interesting how 
these refactorings aren't always

201
00:09:34,280 --> 00:09:36,320
isolated actions. 
You mentioned they can be 

202
00:09:36,320 --> 00:09:39,560
combined performed in sequence. 
Yes, very much so. 

203
00:09:40,080 --> 00:09:43,120
Refactoring is often an 
iterative process combining 

204
00:09:43,120 --> 00:09:44,840
techniques to achieve a larger 
goal. 

205
00:09:45,320 --> 00:09:47,200
The source gives a nice little 
example of this. 

206
00:09:47,200 --> 00:09:49,680
How does that work? 
OK, imagine you start with a 

207
00:09:49,680 --> 00:09:53,520
method F in Class A, and inside 
F there are two chunks of work. 

208
00:09:53,520 --> 00:09:56,440
Let's call them statement S1 
followed by statement S2. 

209
00:09:56,520 --> 00:10:00,040
OK, F does S1 then S2. 
Now you might look at S2 and 

210
00:10:00,040 --> 00:10:02,720
think that's a distinct piece of
logic. 

211
00:10:03,200 --> 00:10:04,800
So your first step could be an 
extract method. 

212
00:10:04,800 --> 00:10:08,680
You pull S2 out into its own new
method, say G still within Class

213
00:10:08,840 --> 00:10:10,840
A. 
So now F just does S1 and then 

214
00:10:10,840 --> 00:10:12,600
calls this G. 
Exactly. 

215
00:10:12,960 --> 00:10:16,560
But then you look at this new 
method G and you realize based 

216
00:10:16,560 --> 00:10:19,560
on what it does, maybe it's 
actually more related to Class B

217
00:10:19,800 --> 00:10:23,520
uses BS data or services. 
So the extraction revealed a 

218
00:10:23,520 --> 00:10:25,600
misplaced responsibility. 
Precisely. 

219
00:10:25,960 --> 00:10:27,760
So the next step is a move 
method. 

220
00:10:28,480 --> 00:10:32,560
You move method G from Class A 
over to Class B OK, so the final

221
00:10:32,560 --> 00:10:36,800
state is Method F in Class A 
still does S1, but now instead 

222
00:10:36,800 --> 00:10:40,400
of calling this dot G, it calls 
BG, invoking the method on an 

223
00:10:40,400 --> 00:10:41,880
instance of Class B. 
Wow. 

224
00:10:41,880 --> 00:10:45,720
So extract followed by move. 
Two smaller steps to achieve a 

225
00:10:45,720 --> 00:10:47,800
significant structural change, 
Yes. 

226
00:10:48,080 --> 00:10:51,160
It shows how you can use these 
refactorings like building 

227
00:10:51,160 --> 00:10:52,840
blocks. 
You don't have to refactor the 

228
00:10:52,840 --> 00:10:56,360
whole world at once. 
Small, deliberate steps, often 

229
00:10:56,360 --> 00:10:59,360
combining techniques, lead to 
much better, more maintainable 

230
00:10:59,360 --> 00:11:01,880
designs overtime. 
That really highlights the craft

231
00:11:01,880 --> 00:11:03,560
involved. 
It's not just banging out code, 

232
00:11:03,560 --> 00:11:06,360
it's thoughtfully shaping it, 
making it easier to understand, 

233
00:11:06,360 --> 00:11:09,840
maintain and evolve later on. 
So wrapping up our deep dive 

234
00:11:09,840 --> 00:11:12,880
today, we've seen inline method 
as a way to clean up tiny, 

235
00:11:12,880 --> 00:11:15,680
underused functions. 
And move method is a really 

236
00:11:15,680 --> 00:11:18,000
powerful technique for getting 
functionality into the right 

237
00:11:18,000 --> 00:11:21,600
class, boosting cohesion and 
cutting down problematic 

238
00:11:21,600 --> 00:11:23,680
dependencies. 
And it's crucial to remember 

239
00:11:23,680 --> 00:11:25,520
these aren't just cosmetic 
changes. 

240
00:11:26,200 --> 00:11:28,720
Refactoring like this is 
fundamental to managing 

241
00:11:28,720 --> 00:11:31,560
technical debt and ensuring 
software can adapt to future 

242
00:11:31,560 --> 00:11:33,960
needs. 
It's about building systems that

243
00:11:33,960 --> 00:11:36,000
last. 
Thank you for joining us on this

244
00:11:36,000 --> 00:11:36,400
deep dive.