1

00:00:00,950  -->  00:00:06,900
Not let's be clear of you I don't want to be from Effective Java which says prefer class hierarchies

2

00:00:07,080  -->  00:00:09,460
to tactlessness.

3

00:00:09,810  -->  00:00:13,190
We know that this is a class hierarchy for present bookmarks.

4

00:00:13,230  -->  00:00:17,130
It has four classes with one super class and three subprocess.

5

00:00:17,640  -->  00:00:23,790
Just note that in addition Weiss the abstractness bookmark is specifically marked with the keyword abstract

6

00:00:24,090  -->  00:00:25,510
right about the class.

7

00:00:25,710  -->  00:00:33,280
OK an item says that we need to use such a class hierarchy instead of a bag class.

8

00:00:33,330  -->  00:00:37,720
So let's look at what a that class as on why we shouldn't use it.

9

00:00:38,270  -->  00:00:43,920
Here is an example of a stack class and with this design instead of four classes we know how only one

10

00:00:43,920  -->  00:00:51,480
class which is the bookmark us so no separate classes to represent weblink movie and book bookmark itself

11

00:00:51,490  -->  00:00:51,580
.

12

00:00:51,670  -->  00:00:57,420
Below represent these entities and for the sake of brevity some of the information has been left out

13

00:00:57,820  -->  00:01:03,850
only a few fees related to movie unbroke are included and that's sufficient to understand what it across

14

00:01:03,900  -->  00:01:04,330
.

15

00:01:05,100  -->  00:01:10,920
Basically the way it works is it inkers instance variables are relevant to both movie and book.

16

00:01:11,090  -->  00:01:16,890
When a bookmark object is created and if it is off by book then only feels relevant to book or initialized

17

00:01:16,900  -->  00:01:17,540
.

18

00:01:18,060  -->  00:01:24,780
For example as much as a book then co-anchored would invoke the first constructor and pass the title

19

00:01:24,780  -->  00:01:27,700
of the book as well as the authors of the book.

20

00:01:27,870  -->  00:01:33,960
So only that relevant instance variables Baida and authors get initialized while the other movie related

21

00:01:33,960  -->  00:01:37,870
variables like directors and cast are just ignored.

22

00:01:38,400  -->  00:01:43,740
Also there is this field called bookmark type which will be initialized the w book.

23

00:01:44,400  -->  00:01:51,480
So the more course information about the type of book mark and be referred to it as the backfield as

24

00:01:51,480  -->  00:01:56,610
it is kind of tagging the bookmark object as either a book or a movie.

25

00:01:56,720  -->  00:02:02,190
Nice bookmark is a movie then client code would invoke the second constructor and would pass the title

26

00:02:02,190  -->  00:02:06,540
of the movie as well as the directors of the movie along with the cast permission.

27

00:02:06,680  -->  00:02:11,730
Not only instance variables are relevant to movie or initialized Well author's field is left untouched

28

00:02:12,240  -->  00:02:17,610
and marked by variable will now be initialized with the value Maulvi just know that.

29

00:02:17,610  -->  00:02:24,120
In this class if multiple values are to be assigned to variables like auteurs detectors on cast then

30

00:02:24,120  -->  00:02:27,950
those values would be concatenated in some way to form a string.

31

00:02:27,960  -->  00:02:30,650
Example would be a comma operator list.

32

00:02:30,750  -->  00:02:35,970
It is fine for this discussion but in practice you should avoid using such kind of concatenated values

33

00:02:35,970  -->  00:02:36,550
.

34

00:02:36,630  -->  00:02:41,190
You would instead use Arrius or other data structures like orderless.

35

00:02:41,190  -->  00:02:46,650
Next if you look at ease keep friendly eligible motet you can notice that it includes separate logic

36

00:02:46,770  -->  00:02:49,190
depending on the type of book 1.

37

00:02:49,740  -->  00:02:56,070
So basically the item in effective Java says that we shouldn't design such a class due to several reasons

38

00:02:56,220  -->  00:02:59,380
that are evident here in this illustration.

39

00:02:59,820  -->  00:03:06,030
One reason is it is boss that is you have multiple constructors too many feels on too much of logic

40

00:03:06,120  -->  00:03:08,380
and one single method.

41

00:03:08,400  -->  00:03:13,350
Second reason is it is error prone as you are trying to represent too many things in the same class

42

00:03:13,350  -->  00:03:14,190
.

43

00:03:14,200  -->  00:03:19,860
Recall the classes should be designed with single responsibility principle which was discussed in coding

44

00:03:19,860  -->  00:03:20,570
conventions.

45

00:03:20,580  -->  00:03:24,020
Listen Finally it is inefficient.

46

00:03:24,300  -->  00:03:29,950
That is English memory footprint as any object will include some irrelevant feats.

47

00:03:30,060  -->  00:03:36,030
For example when creating a book object we need to unnecessarily look at space for the variables directors

48

00:03:36,070  -->  00:03:37,430
and uncashed.

49

00:03:37,560  -->  00:03:39,440
So that's not good.

50

00:03:39,510  -->  00:03:43,350
So basically that class is not good and sometimes out of ignorance.

51

00:03:43,350  -->  00:03:45,810
Engineers might write such process.

52

00:03:45,930  -->  00:03:48,070
We don't know that we shouldn't do this.

53

00:03:48,110  -->  00:03:50,310
Since Julys an object oriented language.

54

00:03:50,460  -->  00:03:57,110
We should try to use it class hierarchy like the way we have done for the bookmark process.

55

00:03:57,210  -->  00:04:00,760
Now in case you encounter that class you may want refactoring.

56

00:04:01,000  -->  00:04:02,750
And let's see how that can be done.

57

00:04:02,820  -->  00:04:06,380
Let's just refactor our Mark back to us.

58

00:04:06,990  -->  00:04:09,960
Make the backglass an abstract class.

59

00:04:10,170  -->  00:04:16,310
Also make every method whose behavior depends on the track field as an abstract method.

60

00:04:16,410  -->  00:04:19,270
In our case we have only one such method.

61

00:04:19,410  -->  00:04:25,200
If there are any methods that do not depend on the fact free let them remain as concrete methods in

62

00:04:25,200  -->  00:04:25,760
our example.

63

00:04:25,770  -->  00:04:27,720
We do not have such methods.

64

00:04:27,720  -->  00:04:33,780
Similarly if there are any fields that are used by all types of that class then those fields should

65

00:04:33,780  -->  00:04:35,970
be in this abstract class.

66

00:04:35,970  -->  00:04:42,980
And in our example it would be the ideal variable as title applies to both movies as well as book.

67

00:04:43,560  -->  00:04:48,520
Next we find a concrete subclass for each type of duck back to us.

68

00:04:48,660  -->  00:04:54,390
The concrete classes should override the abstract methods in the superclass thus providing a specific

69

00:04:54,390  -->  00:04:56,190
implementation.

70

00:04:56,190  -->  00:05:02,620
Finally most any subclass specific variables from superclass include a corresponding subclass.

71

00:05:02,640  -->  00:05:09,180
So the more authors to book class and drippers on cost to movie class with this design there are no

72

00:05:09,180  -->  00:05:13,500
more irrelevant things and the code is simple and clear.

73

00:05:13,500  -->  00:05:19,800
Another advantage is that the code can lead to better design and more flexibility.

74

00:05:19,800  -->  00:05:25,400
For example let's say we want to create an ebook as a special type of book.

75

00:05:25,710  -->  00:05:31,440
Then we can simply create a new class called ebook which would extend the bookless under present in

76

00:05:31,440  -->  00:05:38,970
the same with a class could lead to more confusing or so as we know inheritance Palmet better design

77

00:05:39,900  -->  00:05:44,760
and we are also not touching our own code and we are simply introducing this new class.

78

00:05:45,060  -->  00:05:47,820
So that's the flexibility aspect.

79

00:05:47,820  -->  00:05:54,420
So in summary you should prefer using a class hierarchy and in case you want to attack class C if you

80

00:05:54,420  -->  00:05:57,480
want to refactor it into a class hierarchy.

81

00:05:57,480  -->  00:05:57,840
Thank you
