1
00:00:00,005 --> 00:00:02,008
- [Instructor] Software is built to change,

2
00:00:02,008 --> 00:00:05,008
and to enable that change without breaking it,

3
00:00:05,008 --> 00:00:08,001
one of the most important activities

4
00:00:08,001 --> 00:00:10,005
that must be performed while building an application

5
00:00:10,005 --> 00:00:11,008
is refactoring.

6
00:00:11,008 --> 00:00:16,003
Refactoring means changing internal structure of software

7
00:00:16,003 --> 00:00:20,000
to make it easier to understand and cheaper to modify

8
00:00:20,000 --> 00:00:23,008
while maintaining its external behavior.

9
00:00:23,008 --> 00:00:27,004
Since it is about changing software's internal structure,

10
00:00:27,004 --> 00:00:30,000
we can think about in two ways.

11
00:00:30,000 --> 00:00:32,008
First, making the code maintainable.

12
00:00:32,008 --> 00:00:35,002
This means making it easier to read

13
00:00:35,002 --> 00:00:37,004
by following good coding conventions,

14
00:00:37,004 --> 00:00:40,002
naming methods and variables meaningfully,

15
00:00:40,002 --> 00:00:43,005
moving the code around to help understand the flow,

16
00:00:43,005 --> 00:00:44,005
and so on.

17
00:00:44,005 --> 00:00:47,003
Second, making the design extensible

18
00:00:47,003 --> 00:00:49,005
so that we can keep adding new functionalities

19
00:00:49,005 --> 00:00:53,004
and improving its nonfunctional characteristics,

20
00:00:53,004 --> 00:00:58,002
such as performance, security, usability, et cetera.

21
00:00:58,002 --> 00:00:59,005
A great way to do this

22
00:00:59,005 --> 00:01:01,008
is to apply design patterns,

23
00:01:01,008 --> 00:01:05,002
such as Gang of Four, SOLID, GRASP, and many more.

24
00:01:05,002 --> 00:01:08,000
But, before we start refactoring the code,

25
00:01:08,000 --> 00:01:11,006
we need to make sure that we do not break something

26
00:01:11,006 --> 00:01:13,000
which is already working,

27
00:01:13,000 --> 00:01:17,001
and so here are some best practices to keep in mind.

28
00:01:17,001 --> 00:01:20,006
Ensure that you have complete test suite ready,

29
00:01:20,006 --> 00:01:23,001
and use it to test the application

30
00:01:23,001 --> 00:01:25,005
before and after refactoring.

31
00:01:25,005 --> 00:01:28,009
Do not add any new features when you are refactoring

32
00:01:28,009 --> 00:01:31,001
because this will confuse the issue.

33
00:01:31,001 --> 00:01:34,009
Design patterns are great only when used wisely.

34
00:01:34,009 --> 00:01:37,006
Do not force them into your design.

35
00:01:37,006 --> 00:01:42,006
And, if possible, dedicate a special sprint for refactoring.

36
00:01:42,006 --> 00:01:45,001
Now, with these best practices in mind,

37
00:01:45,001 --> 00:01:47,008
let us see what we have in Red30.

38
00:01:47,008 --> 00:01:49,005
Here is a summary package diagram

39
00:01:49,005 --> 00:01:52,006
of what we have developed so far.

40
00:01:52,006 --> 00:01:56,000
We started with DataLoader and Dao

41
00:01:56,000 --> 00:01:58,001
Dao is central to our application

42
00:01:58,001 --> 00:02:02,005
because it helps all of the classes connect to the database.

43
00:02:02,005 --> 00:02:04,000
Dao uses beans

44
00:02:04,000 --> 00:02:07,001
to encapsulate the data read from the database.

45
00:02:07,001 --> 00:02:09,002
Then we have search and compare packages

46
00:02:09,002 --> 00:02:10,005
that depend on Dao

47
00:02:10,005 --> 00:02:13,004
to get food, product, and nutrients data.

48
00:02:13,004 --> 00:02:17,004
Login which uses Dao to get user authentication data,

49
00:02:17,004 --> 00:02:20,005
and record meal and diet log packages

50
00:02:20,005 --> 00:02:23,005
that need Dao to read and write meal

51
00:02:23,005 --> 00:02:25,005
and servings related data.

52
00:02:25,005 --> 00:02:27,007
When you see one class catering

53
00:02:27,007 --> 00:02:30,002
to so many other packages and classes,

54
00:02:30,002 --> 00:02:33,003
you should begin to see some red flags.

55
00:02:33,003 --> 00:02:34,007
If you look into Dao,

56
00:02:34,007 --> 00:02:39,001
you will see that it is doing almost entire data processing

57
00:02:39,001 --> 00:02:41,005
for all used cases in terms of products,

58
00:02:41,005 --> 00:02:45,008
nutrients, meals, servings, and users.

59
00:02:45,008 --> 00:02:48,001
This reveals two big problems.

60
00:02:48,001 --> 00:02:50,009
Dao is a highly coupled class

61
00:02:50,009 --> 00:02:53,004
because it is talking almost to all of the classes

62
00:02:53,004 --> 00:02:54,006
in the application.

63
00:02:54,006 --> 00:02:57,001
If I need to make any change in Dao,

64
00:02:57,001 --> 00:02:59,008
I might break something or the other somewhere,

65
00:02:59,008 --> 00:03:01,003
and because of that,

66
00:03:01,003 --> 00:03:03,002
I'll have to perform extensive testing

67
00:03:03,002 --> 00:03:05,008
every time I change Dao.

68
00:03:05,008 --> 00:03:10,000
Second, the Dao class has very low cohesion.

69
00:03:10,000 --> 00:03:12,001
It is trying to do too many things.

70
00:03:12,001 --> 00:03:15,003
It is like what is known as a God object.

71
00:03:15,003 --> 00:03:16,008
And these two problems

72
00:03:16,008 --> 00:03:20,003
are leading to violation of the first solid principle

73
00:03:20,003 --> 00:03:22,005
that is single responsibility.

74
00:03:22,005 --> 00:03:25,005
According to single responsibility principle,

75
00:03:25,005 --> 00:03:28,005
a class should have a single reason to change.

76
00:03:28,005 --> 00:03:31,008
Obviously, Dao has too many reasons to change.

77
00:03:31,008 --> 00:03:36,000
So, let us fix that by splitting it into multiple classes.

78
00:03:36,000 --> 00:03:39,004
One way to do this is to create a data layer

79
00:03:39,004 --> 00:03:41,003
with one Dao dedicated

80
00:03:41,003 --> 00:03:43,001
for maintaining the database connection,

81
00:03:43,001 --> 00:03:47,006
and create other Daos to handle other types of data.

82
00:03:47,006 --> 00:03:51,009
So here, I have UserDao that has one validate user method,

83
00:03:51,009 --> 00:03:53,004
which handles user data.

84
00:03:53,004 --> 00:03:57,004
MealDao, that has methods for saving or reading meals

85
00:03:57,004 --> 00:03:59,003
and servings related data,

86
00:03:59,003 --> 00:04:03,004
and USDADao that reads the product and nutrients data.

87
00:04:03,004 --> 00:04:07,006
I have put all these classes in one package named datalayer.

88
00:04:07,006 --> 00:04:08,009
If we make this change,

89
00:04:08,009 --> 00:04:11,008
you can see that Dao is much lighter now

90
00:04:11,008 --> 00:04:14,000
and couples only with other classes

91
00:04:14,000 --> 00:04:15,009
within the datalayer package.

92
00:04:15,009 --> 00:04:18,005
Each of the other Daos couple with classes

93
00:04:18,005 --> 00:04:20,004
of their respective used cases.

94
00:04:20,004 --> 00:04:23,000
UserDao will be used by login classes.

95
00:04:23,000 --> 00:04:26,001
MealDao will be used by classes and record meal

96
00:04:26,001 --> 00:04:27,007
and diet log packages.

97
00:04:27,007 --> 00:04:29,007
And USDADao will be used by classes

98
00:04:29,007 --> 00:04:33,002
in search and compare packages.

99
00:04:33,002 --> 00:04:36,001
There are many more improvements you can make in the code

100
00:04:36,001 --> 00:04:37,008
that I have given to you.

101
00:04:37,008 --> 00:04:40,000
For example, you could look into combining

102
00:04:40,000 --> 00:04:43,008
some of the servlets and removing code redundancy.

103
00:04:43,008 --> 00:04:46,006
Renaming any of the classes, methods,

104
00:04:46,006 --> 00:04:49,000
and variables a little more meaningfully,

105
00:04:49,000 --> 00:04:50,009
and applying design patterns

106
00:04:50,009 --> 00:04:54,000
for future extensibility.