1
00:00:00,040 --> 00:00:03,000
OK, let's dive straight in. 
We're picking U with a really 

2
00:00:03,000 --> 00:00:04,920
foundational refactoring 
strategy. 

3
00:00:05,560 --> 00:00:08,160
Extract class. 
This isn't just tightening U 

4
00:00:08,160 --> 00:00:10,560
right? 
It's about really clarifying 

5
00:00:10,560 --> 00:00:14,880
responsibilities when a class 
starts getting, well, bloated. 

6
00:00:14,920 --> 00:00:17,120
Exactly. 
Bloated is a good word for it. 

7
00:00:17,320 --> 00:00:20,400
You see a class accumulating way
too many attributes, maybe 

8
00:00:20,400 --> 00:00:22,000
handling too many different 
jobs. 

9
00:00:22,240 --> 00:00:25,400
That's the signal. 
It often points to a violation 

10
00:00:25,400 --> 00:00:28,880
of the the Single Responsibility
principle. 

11
00:00:28,880 --> 00:00:30,080
Right. 
One class, one job. 

12
00:00:30,200 --> 00:00:32,960
Pretty much. 
So if you spot attributes or 

13
00:00:32,960 --> 00:00:35,320
responsibilities within that 
class that kind of feel like 

14
00:00:35,320 --> 00:00:37,680
they belong together, like they 
form their own little group, 

15
00:00:37,840 --> 00:00:40,000
extract classes. 
OK, pull that group out. 

16
00:00:40,000 --> 00:00:42,760
Create a new class for them. 
And the original class then just

17
00:00:44,000 --> 00:00:45,480
holds an instance of that new 
class. 

18
00:00:45,480 --> 00:00:47,400
Precisely. 
It gets an attribute of this new

19
00:00:47,400 --> 00:00:49,320
type you just created. 
It delegates the work. 

20
00:00:49,320 --> 00:00:51,840
It cleans up the boundaries, 
makes things much more logical. 

21
00:00:51,840 --> 00:00:54,920
The book uses a good example, 
the Person class holding all the

22
00:00:54,920 --> 00:00:58,920
phone details directly like area
code, number, alternative area 

23
00:00:58,920 --> 00:01:02,360
code all stuffed into Person. 
Yeah, that's a classic. 

24
00:01:02,840 --> 00:01:05,480
Initially it might seem OK, 
maybe convenient even. 

25
00:01:05,840 --> 00:01:08,600
But pretty quickly that person 
class starts knowing way too 

26
00:01:08,600 --> 00:01:10,840
much about phones. 
It's less focused. 

27
00:01:10,920 --> 00:01:14,560
So the fix is. 
You create a new Phone class, it

28
00:01:14,560 --> 00:01:16,240
holds the area code and the 
number. 

29
00:01:16,600 --> 00:01:19,520
Then back in the Person class, 
instead of all those individual 

30
00:01:19,520 --> 00:01:23,920
phone fields, you just have say 
a home Phone object and maybe a 

31
00:01:23,920 --> 00:01:26,280
work phone object. 
Both are of type Phone. 

32
00:01:26,760 --> 00:01:29,800
Oh OK, so person doesn't care 
how the phone number is 

33
00:01:29,800 --> 00:01:30,960
structured anymore. 
Exactly. 

34
00:01:30,960 --> 00:01:33,600
It just knows it has phones. 
It improves modularity 

35
00:01:33,600 --> 00:01:37,680
massively, the codes intent is 
way clearer and responsibilities

36
00:01:37,680 --> 00:01:40,720
are split up properly. 
Makes reasoning about each part 

37
00:01:40,720 --> 00:01:43,520
much easier. 
And you know this idea connects 

38
00:01:43,520 --> 00:01:47,240
to extract interface to similar 
principal different mechanism. 

39
00:01:47,240 --> 00:01:48,760
Like with link list and array 
list. 

40
00:01:48,760 --> 00:01:50,840
Perfect example. 
They're both list right, but 

41
00:01:50,880 --> 00:01:53,320
implemented differently. 
So you extract a common list 

42
00:01:53,320 --> 00:01:55,200
interface. 
This defines the shared 

43
00:01:55,200 --> 00:01:57,920
behaviors, adding items, 
removing them, getting the size,

44
00:01:57,920 --> 00:02:00,160
stuff like that. 
And the benefit for, you know, 

45
00:02:00,240 --> 00:02:03,120
for us coding against it. 
The big win is you start 

46
00:02:03,120 --> 00:02:06,600
following that prefer interfaces
to concrete classes idea. 

47
00:02:07,080 --> 00:02:11,200
If your code uses the List 
interface, you can easily swap 

48
00:02:11,200 --> 00:02:14,280
an array list for a link list or
something else entirely. 

49
00:02:14,560 --> 00:02:17,080
And your code doesn't break. 
It doesn't care about the 

50
00:02:17,080 --> 00:02:19,680
specific implementation, just 
the list contract. 

51
00:02:20,040 --> 00:02:23,440
That's huge for flexibility. 
So looking at your own code, 

52
00:02:23,760 --> 00:02:27,200
this kind of thinking, breaking 
things down, defining clear 

53
00:02:27,200 --> 00:02:31,200
interfaces is really crucial. 
It stops those huge God like 

54
00:02:31,200 --> 00:02:34,280
classes from forming, makes 
things easier to grasp, easier 

55
00:02:34,280 --> 00:02:36,920
to test, and yeah, easier to 
reuse later on. 

56
00:02:37,120 --> 00:02:38,320
Helps you move faster in the 
long run. 

57
00:02:38,680 --> 00:02:41,400
OK, moving on from structure to 
meaning, let's talk about 

58
00:02:41,400 --> 00:02:45,120
renaming. 
Naming things the famous hard 

59
00:02:45,120 --> 00:02:46,640
problem in computer science, 
right? 

60
00:02:47,160 --> 00:02:48,800
Besides cash and validation, of 
course. 

61
00:02:49,000 --> 00:02:52,040
Yeah, the quote holds up. 
Naming is deceptively difficult.

62
00:02:52,040 --> 00:02:54,720
Why is it so hard and why do we 
constantly find ourselves 

63
00:02:54,720 --> 00:02:57,080
renaming things? 
Well, there are usually a couple

64
00:02:57,080 --> 00:02:59,040
of reasons. 
Sometimes, honestly, the first 

65
00:02:59,040 --> 00:03:01,760
name just wasn't very good. 
Not clear, not descriptive 

66
00:03:01,760 --> 00:03:03,760
enough. 
We've all written temp or data 

67
00:03:03,760 --> 00:03:06,480
one. 
Or maybe more often in systems 

68
00:03:06,480 --> 00:03:10,400
that live a long time, the thing
itself changes, its purpose 

69
00:03:10,400 --> 00:03:13,120
evolves. 
A method initially called 

70
00:03:13,120 --> 00:03:17,240
Calculate tax might later also 
handle applying discounts, so 

71
00:03:17,240 --> 00:03:20,800
the name becomes misleading. 
And a misleading name is just 

72
00:03:20,800 --> 00:03:24,080
asking for trouble, 
misinterpretations, bugs. 

73
00:03:24,120 --> 00:03:26,520
Exactly. 
Good names are vital for 

74
00:03:26,520 --> 00:03:29,040
comprehension. 
They reduce that cognitive load 

75
00:03:29,040 --> 00:03:32,280
when someone else, or even you 
six months later reads the code.

76
00:03:32,480 --> 00:03:35,320
But the tricky part isn't always
finding the better name. 

77
00:03:35,600 --> 00:03:38,480
It's updating everywhere the old
name was used, right? 

78
00:03:38,920 --> 00:03:41,760
That sounds risky it. 
Can be definitely. 

79
00:03:41,840 --> 00:03:44,760
Especially in a big system where
a method or class is used all 

80
00:03:44,760 --> 00:03:47,080
over the place. 
Miss one reference and boom, 

81
00:03:47,080 --> 00:03:50,080
runtime error. 
It's tedious and error prone. 

82
00:03:50,120 --> 00:03:52,880
How do we do it more safely? 
The book suggests safer approach

83
00:03:52,880 --> 00:03:55,040
using deprecation. 
Let's say you want to rename 

84
00:03:55,040 --> 00:03:58,760
method F to G First you create 
the new method G You copy the 

85
00:03:58,760 --> 00:04:02,480
original code from F into G Then
you go back to the old method F 

86
00:04:02,480 --> 00:04:05,920
You mark it with at deprecated. 
That's a special annotation, OK.

87
00:04:05,920 --> 00:04:07,880
What does at deprecated actually
do? 

88
00:04:08,040 --> 00:04:10,520
It's a signal primarily to the 
compiler. 

89
00:04:10,520 --> 00:04:14,240
In your IDE it says, hey, this 
thing is outdated, you probably 

90
00:04:14,240 --> 00:04:17,200
shouldn't use it anymore. 
Compilers will usually issue 

91
00:04:17,200 --> 00:04:20,079
warnings if someone tries to 
call the deprecated method F. 

92
00:04:20,839 --> 00:04:24,320
So it warns developers and what 
happens inside F now? 

93
00:04:24,520 --> 00:04:28,160
Inside the deprecated method F 
you just put a single line, a 

94
00:04:28,160 --> 00:04:32,080
call to the new method G So F 
now just delegates to G. 

95
00:04:32,160 --> 00:04:34,120
Got it. 
So old code calling F still 

96
00:04:34,120 --> 00:04:38,560
works, but developers get warned
and the actual logic lives in G.

97
00:04:38,600 --> 00:04:40,360
Exactly. 
It's like putting up a detour 

98
00:04:40,360 --> 00:04:42,320
sign. 
The old road still gets you 

99
00:04:42,320 --> 00:04:45,040
there for now, but everyone's 
encouraged to use the new 

100
00:04:45,040 --> 00:04:46,560
highway. 
That makes so much sense. 

101
00:04:46,560 --> 00:04:49,600
It doesn't force everyone to 
update instantly, gives teams 

102
00:04:49,600 --> 00:04:51,520
time to adapt. 
Much safer. 

103
00:04:51,520 --> 00:04:54,680
Yeah, it embraces that idea of 
making changes in small, safe 

104
00:04:54,680 --> 00:04:57,360
steps, baby steps, avoids 
breaking things. 

105
00:04:57,560 --> 00:05:00,280
It really reflects a core 
principle for managing large 

106
00:05:00,280 --> 00:05:03,480
software projects. 
Introduce change gradually 

107
00:05:03,720 --> 00:05:06,200
manage the risk, allow for 
transition. 

108
00:05:06,200 --> 00:05:08,240
Makes sense. 
Stability is key. 

109
00:05:08,240 --> 00:05:10,240
Absolutely. 
Especially when you have complex

110
00:05:10,240 --> 00:05:12,600
dependencies, you minimize 
disruption. 

111
00:05:12,960 --> 00:05:15,800
Then later, once everyone's 
migrated to G, you can safely 

112
00:05:15,800 --> 00:05:17,920
delete F. 
OK, great strategy. 

113
00:05:18,240 --> 00:05:21,840
Now let's shift gears slightly. 
We've talked big structure 

114
00:05:21,840 --> 00:05:25,640
changes like extract glass and 
crucial clarity changes like 

115
00:05:25,640 --> 00:05:29,120
renaming. 
What about those smaller, more 

116
00:05:29,120 --> 00:05:31,960
localized improvements? 
Things you might do just inside 

117
00:05:31,960 --> 00:05:34,880
a single method. 
Yeah, there are several really 

118
00:05:34,880 --> 00:05:37,440
useful ones for that fine green 
cleanup. 

119
00:05:37,840 --> 00:05:40,360
They might seem small, but they 
add up significantly for 

120
00:05:40,360 --> 00:05:42,680
readability and maintainability.
Like what? 

121
00:05:43,400 --> 00:05:45,600
Well, first up is extract 
variable. 

122
00:05:45,920 --> 00:05:48,800
This is all about simplifying 
complex expressions. 

123
00:05:49,080 --> 00:05:51,520
Imagine you have a long 
calculation, maybe part of a 

124
00:05:51,520 --> 00:05:53,600
formula, all crammed into one 
line. 

125
00:05:53,800 --> 00:05:56,200
It can be hard to read, hard to 
see the structure. 

126
00:05:56,360 --> 00:05:59,080
Right, like nested function 
calls or complex math. 

127
00:05:59,080 --> 00:06:02,160
Exactly. 
So extract variable says, take a

128
00:06:02,160 --> 00:06:05,120
meaningful chunk of that complex
expression, calculate it 

129
00:06:05,120 --> 00:06:08,480
separately and assign the result
to a new variable with a good 

130
00:06:08,480 --> 00:06:11,560
descriptive name. 
So you break it down, give names

131
00:06:11,560 --> 00:06:13,680
to the intermediate steps. 
Precisely. 

132
00:06:14,200 --> 00:06:17,520
The book might show something 
like pulling out the BB fourac 

133
00:06:17,520 --> 00:06:20,680
ache part of the quadratic 
formula into a variable called 

134
00:06:20,680 --> 00:06:23,320
delta or discriminate. 
The original formula then 

135
00:06:23,320 --> 00:06:26,800
becomes shorter, uses delta, and
is immediately easier to 

136
00:06:26,800 --> 00:06:28,760
understand. 
Reduces the mental juggling. 

137
00:06:28,760 --> 00:06:30,360
OK, that's clear. 
Makes sense. 

138
00:06:30,560 --> 00:06:32,400
What else? 
Remove flag. 

139
00:06:33,080 --> 00:06:36,520
This one targets those boolean 
flag variables we sometimes use 

140
00:06:36,520 --> 00:06:39,280
to control loops or signal 
results within a method. 

141
00:06:39,280 --> 00:06:42,360
Like setting found in true 
inside a loop when you find what

142
00:06:42,360 --> 00:06:44,400
you're looking for. 
That's the classic example. 

143
00:06:44,400 --> 00:06:46,680
You loop through something, 
maybe searching an array. 

144
00:06:46,960 --> 00:06:49,480
If you find the item you set, 
found a true and then maybe 

145
00:06:49,480 --> 00:06:51,840
break. 
After the loop, you check if 

146
00:06:51,840 --> 00:06:54,360
found. 
The refactoring suggests getting

147
00:06:54,360 --> 00:06:57,840
rid of that found variable 
altogether by using control flow

148
00:06:57,840 --> 00:07:00,440
statements directly. 
As soon as you find the item 

149
00:07:00,440 --> 00:07:02,640
inside the loop, just return 
true right there. 

150
00:07:02,880 --> 00:07:05,560
If the loop finishes without 
finding it, you return false 

151
00:07:05,560 --> 00:07:07,960
after the loop. 
OK, direct exit. 

152
00:07:08,120 --> 00:07:11,560
Yeah, it eliminates the need for
the flag variable less state to 

153
00:07:11,560 --> 00:07:14,600
track cleaner flow. 
Often shorter code makes the 

154
00:07:14,600 --> 00:07:16,800
exit condition more explicit. 
Nice. 

155
00:07:17,280 --> 00:07:19,280
I like that fewer variables is 
usually good. 

156
00:07:19,440 --> 00:07:21,320
Definitely. 
Then there's a really powerful 

157
00:07:21,320 --> 00:07:23,320
one. 
Replace conditional with 

158
00:07:23,320 --> 00:07:26,440
polymorphism. 
Oh, OK, polymorphism. 

159
00:07:26,760 --> 00:07:30,160
This sounds more involved. 
It is, but it's fantastic for 

160
00:07:30,160 --> 00:07:34,040
cleaning up complex switch 
statements or long if else if 

161
00:07:34,040 --> 00:07:37,040
else chains, especially when the
condition is based on the type 

162
00:07:37,040 --> 00:07:38,960
of an object. 
Like checking if student dot 

163
00:07:38,960 --> 00:07:42,520
type equals undergrad then else 
if student dot type master. 

164
00:07:42,520 --> 00:07:45,800
Exactly that kind of scenario. 
The book uses an example like 

165
00:07:45,800 --> 00:07:49,120
calculating a student's research
grant based on their type 

166
00:07:49,120 --> 00:07:53,120
undergrad, master, PhD. 
Instead of that big switch or if

167
00:07:53,120 --> 00:07:56,280
else block in the code that uses
the Student object, the 

168
00:07:56,280 --> 00:07:58,240
refactored code becomes 
incredibly simple. 

169
00:07:58,360 --> 00:08:00,640
Maybe just double grant student 
dot get grant? 

170
00:08:00,680 --> 00:08:03,640
Whoa, OK, how does that work? 
Where did the logic go? 

171
00:08:03,640 --> 00:08:05,760
It leverages object oriented 
programming. 

172
00:08:06,240 --> 00:08:09,240
You make get grant an abstract 
method in a base student class. 

173
00:08:09,240 --> 00:08:13,040
Then each specific subclass 
undergraduate student, master 

174
00:08:13,040 --> 00:08:16,160
student, PhD student provides 
its own implementation of GET 

175
00:08:16,160 --> 00:08:18,480
grant. 
So the logic for the grant 

176
00:08:18,480 --> 00:08:20,920
amount lives inside each student
types class. 

177
00:08:21,200 --> 00:08:25,160
Precisely when you call student 
dot get grant polymorphism 

178
00:08:25,160 --> 00:08:28,080
ensures the correct version of 
the method for that specific 

179
00:08:28,080 --> 00:08:32,120
Student object gets executed. 
It elegantly distributes the 

180
00:08:32,120 --> 00:08:33,679
responsibility. 
That's cool. 

181
00:08:33,840 --> 00:08:36,240
It gets rid of the big 
conditional and makes it easy to

182
00:08:36,240 --> 00:08:39,280
add new student types later 
without modifying the original 

183
00:08:39,280 --> 00:08:40,760
calling code. 
Exactly. 

184
00:08:40,799 --> 00:08:44,280
Much more extensible, adheres 
better to the open closed 

185
00:08:44,280 --> 00:08:46,840
principle. 
And finally a really important 

186
00:08:46,840 --> 00:08:48,840
one, especially in older code 
bases. 

187
00:08:49,120 --> 00:08:51,160
Remove dead code. 
Just. 

188
00:08:51,600 --> 00:08:53,560
Deleting code. 
Just deleting code that isn't 

189
00:08:53,560 --> 00:08:56,440
used anymore, methods that are 
never called classes, never 

190
00:08:56,440 --> 00:08:59,720
instantiated variables or 
attributes, never read stuff 

191
00:08:59,720 --> 00:09:02,120
that's just sitting there. 
That sounds simple, maybe even 

192
00:09:02,120 --> 00:09:03,560
obvious. 
But why is it so important, 

193
00:09:03,960 --> 00:09:06,840
especially in big old projects? 
It's not hurting anything if 

194
00:09:06,840 --> 00:09:10,720
it's not called, is it? 
But it is hurting things 

195
00:09:10,960 --> 00:09:15,120
indirectly in systems maintained
over years by many different 

196
00:09:15,120 --> 00:09:18,520
developers. 
Dead code just accumulates. 

197
00:09:18,520 --> 00:09:20,960
It's inevitable, and it causes 
real problems. 

198
00:09:21,040 --> 00:09:23,200
It's clutter. 
It makes the code base bigger 

199
00:09:23,200 --> 00:09:26,560
and harder to navigate. 
New developers waste time trying

200
00:09:26,560 --> 00:09:28,320
to understand code that does 
nothing. 

201
00:09:28,520 --> 00:09:31,400
They might be afraid to remove 
it, thinking it's used somewhere

202
00:09:31,400 --> 00:09:33,040
they miss. 
Right, that fear factor. 

203
00:09:33,320 --> 00:09:35,080
What if this breaks something 
obscure? 

204
00:09:35,120 --> 00:09:37,480
Exactly. 
It adds confusion and slows down

205
00:09:37,480 --> 00:09:40,000
comprehension. 
Removing it makes the code base 

206
00:09:40,000 --> 00:09:43,360
leaner, cleaner, easier to 
understand, and crucially, 

207
00:09:43,520 --> 00:09:45,800
easier and safer to change going
forward. 

208
00:09:46,200 --> 00:09:48,280
You eliminate the risk of 
someone acts as evidently 

209
00:09:48,280 --> 00:09:51,800
resurrecting old buggy logic. 
It's essential maintenance. 

210
00:09:51,800 --> 00:09:54,280
OK, that makes total sense. 
It's not just tidiness, it's 

211
00:09:54,480 --> 00:09:56,360
risk reduction and 
maintainability. 

212
00:09:56,800 --> 00:09:59,400
So we've covered some really key
refactoring techniques today. 

213
00:09:59,600 --> 00:10:01,400
Extract class for better 
structure. 

214
00:10:01,400 --> 00:10:04,480
Renaming using deprecation for 
safer transitions. 

215
00:10:04,480 --> 00:10:06,800
And those valuable local 
improvements like extract 

216
00:10:06,800 --> 00:10:10,680
variable, remove flag using 
polymorphism over conditional. 

217
00:10:10,680 --> 00:10:13,440
And definitely remove dead code.
Keep that code base clean. 

218
00:10:13,560 --> 00:10:16,840
It really paints a picture of 
refactoring as this ongoing 

219
00:10:16,840 --> 00:10:19,240
process, not a one runoff event.
Absolutely. 

220
00:10:19,240 --> 00:10:22,640
It's about continuous design 
improvement, making sure that as

221
00:10:22,640 --> 00:10:26,160
the software grows and changes, 
the underlying structure stays 

222
00:10:26,160 --> 00:10:28,320
healthy, adaptable and 
maintainable. 

223
00:10:28,480 --> 00:10:31,200
It's an investment really in the
future health of the project. 

224
00:10:31,400 --> 00:10:33,160
Thank you for joining us for 
this deep dive.