19 - Java Collections Framework/015 Hash Tables & HashMap_en.srt

1
00:00:06,000 --> 00:00:11,000
Hello, the students in this lesson, we are going to learn how hash tables work and an example of hash

2
00:00:11,000 --> 00:00:13,000
map will learn how to use maps.

3
00:00:14,000 --> 00:00:19,000
This is important because a lot of the most popular map implementations are based on the hash tables

4
00:00:20,000 --> 00:00:26,000
to understand how hash tables work and how to override equals and hash code methods.

5
00:00:26,000 --> 00:00:29,000
In our times today, we'll have practice with hash map.

6
00:00:30,000 --> 00:00:35,000
You're going to learn what the capacity of hash map is and what load factor is.

7
00:00:35,000 --> 00:00:40,000
I'll share with you the best practices of selecting keys for map urines and lesson.

8
00:00:40,000 --> 00:00:43,000
We are going to answer the question what immutable objects are.

9
00:00:44,000 --> 00:00:48,000
Also, I will show you how you can search entries in your Mambi keys and by values.

10
00:00:48,000 --> 00:00:49,000
Let's start.

11
00:00:50,000 --> 00:00:54,000
Probably you already know from the previous lessons that it takes constant amount of time from hash

12
00:00:54,000 --> 00:01:02,000
map to perform its major operations like get both remove and connotation for major operation of hash.

13
00:01:02,000 --> 00:01:06,000
Map is all of one, but what implementation brings are such performance.

14
00:01:07,000 --> 00:01:13,000
This is because Hashmat the same as Linc's hash map, concurrent hash map and hash table use hash tables

15
00:01:13,000 --> 00:01:14,000
to store and retrieve data.

16
00:01:15,000 --> 00:01:21,000
And for us it is important to understand how hash tables work so that we could use and tune our hash

17
00:01:21,000 --> 00:01:23,000
map when needed for better performance.

18
00:01:23,000 --> 00:01:30,000
Let's learn what hash table is and try to explain hash table in very simple words that are easy to understand.

19
00:01:30,000 --> 00:01:33,000
I can explain it in the Wikipedia language, but I won't.

20
00:01:34,000 --> 00:01:40,000
In simple words, hash table consists of buckets or also sometimes they called slots where you might

21
00:01:40,000 --> 00:01:41,000
put any value.

22
00:01:41,000 --> 00:01:44,000
I want you also to learn things on example.

23
00:01:44,000 --> 00:01:49,000
So we would discuss also a few things that are specific for hash map implementation.

24
00:01:49,000 --> 00:01:53,000
By default, hash map object has initial capacity of sixteen buckets.

25
00:01:53,000 --> 00:01:59,000
That means that at the beginning when we only created hash map object, we have sixteen buckets.

26
00:01:59,000 --> 00:02:02,000
Load factor is equal to zero point seventy five.

27
00:02:03,000 --> 00:02:04,000
What is the load factor.

28
00:02:05,000 --> 00:02:11,000
Load factor is a value that tells when our hash table has to be resized and increased inside the hash

29
00:02:11,000 --> 00:02:15,000
map type you would find in variable with the name threshold.

30
00:02:15,000 --> 00:02:18,000
That is a result of multiplication of capacity and load factor.

31
00:02:19,000 --> 00:02:23,000
So 16 times zero point seventy five equals to twelve.

32
00:02:23,000 --> 00:02:29,000
That means that when twelve buckets will store some value, our hash map will be resized.

33
00:02:29,000 --> 00:02:34,000
After similar situation of hash map source code, we would find that threshold is doubled when we need

34
00:02:34,000 --> 00:02:36,000
to increase our hash map.

35
00:02:36,000 --> 00:02:38,000
One new threshold has reached.

36
00:02:38,000 --> 00:02:44,000
A hash table is rehashed so that the hash table has approximately twice the number of brackets.

37
00:02:44,000 --> 00:02:47,000
Can you understand what capacity and load factor is?

38
00:02:47,000 --> 00:02:53,000
A hash map has specific constructor that allows you to pass integer value to initialize capacity and

39
00:02:53,000 --> 00:02:58,000
flow, add value to initialize load factor in case you want to tune Hashmat performance.

40
00:02:58,000 --> 00:03:01,000
But in real life, default values are used most often.

41
00:03:02,000 --> 00:03:04,000
OK, let's move on now.

42
00:03:04,000 --> 00:03:07,000
Let's imagine that I want to put new entry in my hash map here.

43
00:03:07,000 --> 00:03:11,000
You can see that I have entries that consist of the key and value.

44
00:03:11,000 --> 00:03:14,000
Let it be some string object, key one here and some value.

45
00:03:14,000 --> 00:03:21,000
OK, what happens next after that hash function is applied to compute index of a bucket of the key hash

46
00:03:21,000 --> 00:03:24,000
code, Masset is invoked on the key object.

47
00:03:24,000 --> 00:03:30,000
After we received hash code, we may perform module separation and the reminder would be the index of

48
00:03:30,000 --> 00:03:30,000
a bucket.

49
00:03:31,000 --> 00:03:35,000
After that I place key to the bucket and associated the value with that key.

50
00:03:36,000 --> 00:03:39,000
And after that, each new element is placed in a new bucket.

51
00:03:40,000 --> 00:03:45,000
Based on this, can you understand why adding elements in the hash map always took a constant amount

52
00:03:45,000 --> 00:03:46,000
of time?

53
00:03:46,000 --> 00:03:51,000
Because to put element we need to define bucket for that element and just put it there.

54
00:03:51,000 --> 00:03:54,000
And the separation doesn't depend on a number of elements.

55
00:03:55,000 --> 00:03:58,000
OK, what happens in Case to Case has the same hash called?

56
00:03:59,000 --> 00:04:02,000
The situation may happen because of the hash collision.

57
00:04:02,000 --> 00:04:05,000
I will explain in detail why this might happen a bit later.

58
00:04:06,000 --> 00:04:11,000
For now, just take as a fact that theoretically two different objects may have the same hash code.

59
00:04:11,000 --> 00:04:16,000
According to the flow that I have described, the elements would be put in the same back.

60
00:04:16,000 --> 00:04:19,000
It is a true yes, it is inside.

61
00:04:19,000 --> 00:04:21,000
Each bucket linked list is created.

62
00:04:22,000 --> 00:04:24,000
This is not double list.

63
00:04:24,000 --> 00:04:26,000
It is connected only in one direction.

64
00:04:26,000 --> 00:04:33,000
And it looks like this element in the bucket has reference to the next object with one exception.

65
00:04:33,000 --> 00:04:38,000
In general version eight additional improvement was introduced in performance of hash tables in case

66
00:04:38,000 --> 00:04:41,000
type of key object implements comparable interface.

67
00:04:41,000 --> 00:04:47,000
That means keys might be sorted and in case there are multiple objects in one bucket, there is no link

68
00:04:47,000 --> 00:04:49,000
list with its all of end.

69
00:04:50,000 --> 00:04:52,000
That is linear algorithm complexity.

70
00:04:53,000 --> 00:05:00,000
Instead of the list, there is a binary tree that brings us all of logarithm and complexity of the algorithm.

71
00:05:00,000 --> 00:05:01,000
Does it make sense?

72
00:05:01,000 --> 00:05:02,000
Let's move forward.

73
00:05:03,000 --> 00:05:08,000
To understand why the treatment of animals stay constant amount of time, let me show you how element

74
00:05:08,000 --> 00:05:12,000
is retrieved from the hash map to retrieve elements from the map.

75
00:05:12,000 --> 00:05:13,000
We paskey object.

76
00:05:13,000 --> 00:05:15,000
Hash function is applied to the key.

77
00:05:16,000 --> 00:05:18,000
This allows to define the bucket.

78
00:05:18,000 --> 00:05:22,000
After bucket is defined, keys are checked for quality.

79
00:05:23,000 --> 00:05:23,000
Why?

80
00:05:23,000 --> 00:05:27,000
As you already know, there might be two different objects with the same hash.

81
00:05:27,000 --> 00:05:32,000
That's why algorithm should call equals Masset to compare to objects.

82
00:05:32,000 --> 00:05:37,000
And in the case there are multiple objects in one bucket, algorithm will check a quality until it finds

83
00:05:37,000 --> 00:05:38,000
the match.

84
00:05:39,000 --> 00:05:43,000
That's why it is said that hash code and equals method and work in PR..

85
00:05:43,000 --> 00:05:47,000
Can you stand now on each step hash code and equals method is used.

86
00:05:48,000 --> 00:05:48,000
Awesome.

87
00:05:49,000 --> 00:05:55,000
Now imagine that we have times where we have overridden hash quote masset and hash code returns constant

88
00:05:55,000 --> 00:05:55,000
value.

89
00:05:55,000 --> 00:05:57,000
Imagine that has got message.

90
00:05:57,000 --> 00:06:00,000
Just looks like this on one all the times.

91
00:06:01,000 --> 00:06:03,000
What that would mean for the hash map.

92
00:06:03,000 --> 00:06:07,000
That means that bucket for all objects of this type would be the same.

93
00:06:08,000 --> 00:06:13,000
And instead of taking advantage of hash table and constant amount of time for retrieving elements,

94
00:06:13,000 --> 00:06:18,000
we would get linear time because all elements will be stored in one bucket.

95
00:06:19,000 --> 00:06:24,000
That is exactly the reason why we need to override hash code functions that would return the most unique

96
00:06:24,000 --> 00:06:24,000
integer.

97
00:06:25,000 --> 00:06:28,000
Now let's talk about the requirements for hash code and equals mass.

98
00:06:28,000 --> 00:06:34,000
That should be during the methods overriding the three major requirements that hash could function should

99
00:06:34,000 --> 00:06:38,000
meet Zaya multiple invocation of hash code.

100
00:06:38,000 --> 00:06:41,000
MassArt must consistently return the same integer.

101
00:06:41,000 --> 00:06:47,000
The second requirement if two objects are equal, that means if equal message returns true, then the

102
00:06:47,000 --> 00:06:49,000
hash code also should be equal.

103
00:06:50,000 --> 00:06:56,000
What another statement is follows from this rule that fields that that used to compare objects and feel

104
00:06:56,000 --> 00:06:58,000
that they used to calculate hash.

105
00:06:58,000 --> 00:07:00,000
Code of the object should be the same.

106
00:07:00,000 --> 00:07:01,000
Does it make sense?

107
00:07:02,000 --> 00:07:06,000
And the search requirement includes two objects are not equal.

108
00:07:06,000 --> 00:07:08,000
It is possible that hash codes will be the same.

109
00:07:09,000 --> 00:07:10,000
Let me comment on the statement.

110
00:07:11,000 --> 00:07:13,000
Probably you are wondering how this may happen.

111
00:07:13,000 --> 00:07:15,000
It is an easy mass rule.

112
00:07:16,000 --> 00:07:19,000
Hypothetically, the set of objects is infinite.

113
00:07:19,000 --> 00:07:23,000
We can create as much objects as our hip size will allow us.

114
00:07:23,000 --> 00:07:27,000
And as we increase keep size, we can create even more objects than before.

115
00:07:28,000 --> 00:07:34,000
Whereas Hershkowitz value is not infinite, it exists only within the integer range, no more and no

116
00:07:34,000 --> 00:07:35,000
less.

117
00:07:35,000 --> 00:07:39,000
That's why, hypothetically, hedgcock collisions may happen.

118
00:07:39,000 --> 00:07:40,000
Hash collisions.

119
00:07:40,000 --> 00:07:45,000
That is a state when two different objects that are not equal have the same hash.

120
00:07:45,000 --> 00:07:48,000
Could hope that things are clearer now.

121
00:07:49,000 --> 00:07:55,000
Now let's talk about rules that equals that should meet equals mass should meet five rules.

122
00:07:55,000 --> 00:07:57,000
Zaya equals mass.

123
00:07:57,000 --> 00:07:58,000
It should be reflexive.

124
00:07:58,000 --> 00:08:04,000
This means that for any non non reference value x X equals X should return.

125
00:08:04,000 --> 00:08:04,000
True.

126
00:08:05,000 --> 00:08:05,000
That is obvious.

127
00:08:05,000 --> 00:08:10,000
But still it is worth to mention for complete understanding equals mass.

128
00:08:10,000 --> 00:08:12,000
That should be symmetric.

129
00:08:12,000 --> 00:08:19,000
This means that for any non non reference values, X and Y X equals Y should be true if and only if

130
00:08:19,000 --> 00:08:21,000
Y equals X returns.

131
00:08:21,000 --> 00:08:21,000
True.

132
00:08:22,000 --> 00:08:28,000
Equals mass, it shouldn't be transitive for any non reference value is X, Y and Z.

133
00:08:28,000 --> 00:08:37,000
If X equals Y returns true and Y equals that return true, then X equals Z should return true equals

134
00:08:37,000 --> 00:08:37,000
mass.

135
00:08:37,000 --> 00:08:44,000
It should be consistent for any nominal reference values X and Y, multiple invocations of X equals

136
00:08:44,000 --> 00:08:45,000
Y should be consistent.

137
00:08:46,000 --> 00:08:53,000
And last but not the list requirement is that for any non reference value x x equals now should return

138
00:08:53,000 --> 00:08:53,000
false.

139
00:08:54,000 --> 00:08:59,000
A bit later today during the practice, we'll review how to override hash code and equals MassArt.

140
00:09:00,000 --> 00:09:06,000
Let's start our practice exercises, we have in now theoretical knowledge right now to understand the

141
00:09:06,000 --> 00:09:07,000
next examples.

142
00:09:08,000 --> 00:09:13,000
Before the lesson, I prepared a file with examples that will help you to understand how maps work.

143
00:09:14,000 --> 00:09:17,000
Let me run the program and walk you through council output.

144
00:09:17,000 --> 00:09:22,000
Here I declare a map very similar to collection and types.

145
00:09:22,000 --> 00:09:24,000
Map type is also parametrized.

146
00:09:25,000 --> 00:09:31,000
Hope you don't skip lessons about least implementations where I explained on the high level how Diament

147
00:09:31,000 --> 00:09:32,000
operator works.

148
00:09:33,000 --> 00:09:35,000
We're also going to learn genetics and a separate lesson.

149
00:09:35,000 --> 00:09:38,000
So don't worry much about that.

150
00:09:38,000 --> 00:09:45,000
Handyman's operator specifies that keys in this map would have integer type and values and this map

151
00:09:45,000 --> 00:09:48,000
would have string type I initialize.

152
00:09:48,000 --> 00:09:51,000
This object was a reference to the Hashmat object.

153
00:09:51,000 --> 00:09:57,000
If we want to put entries in the map, you can see example here, I just called Put Masset and pass

154
00:09:57,000 --> 00:09:58,000
integer and string.

155
00:09:59,000 --> 00:10:02,000
If I want to get a map, I have to use key.

156
00:10:03,000 --> 00:10:10,000
For example, if I want to retrieve string one, I just want to get MassArt like this and console.

157
00:10:10,000 --> 00:10:16,000
You can see that we printed the values that is associated with the key take into account key set returns,

158
00:10:16,000 --> 00:10:18,000
the implementation of that interface.

159
00:10:18,000 --> 00:10:21,000
And we already know that that extends collection.

160
00:10:21,000 --> 00:10:23,000
That in turn extends iterable.

161
00:10:24,000 --> 00:10:28,000
This means I can use foreach loop to iterate over elements.

162
00:10:29,000 --> 00:10:35,000
And here I printed all keys to console the next thing I want to show you is an example how you might

163
00:10:35,000 --> 00:10:37,000
iterate over all entries in MAP.

164
00:10:38,000 --> 00:10:45,000
I take entries said from my map here and specify in variable here of map entry type since entry interface

165
00:10:45,000 --> 00:10:47,000
is declared inside map interface.

166
00:10:47,000 --> 00:10:50,000
From the syntax standpoint, I have to put DOT here.

167
00:10:51,000 --> 00:10:57,000
My entry will be parametrized by integer and string that the same types that keys and values have.

168
00:10:57,000 --> 00:11:02,000
In my map you can see that I use central variable to retrieve key and value.

169
00:11:05,000 --> 00:11:11,000
Here also damos of the get on the fourth method, I want to draw your attention that in case our entry

170
00:11:11,000 --> 00:11:18,000
exists in the map, like entry was a key for default, value won't be returned even in case the value

171
00:11:18,000 --> 00:11:23,000
is not, the default value will be returned only in case the entry doesn't exist.

172
00:11:23,000 --> 00:11:26,000
And that was entry was the key five.

173
00:11:27,000 --> 00:11:33,000
Would have absolute mass, it will put value associated with the key in case if he is not already associated

174
00:11:33,000 --> 00:11:39,000
with the value or associated with it now and here you can see that I call this method for the entry

175
00:11:39,000 --> 00:11:46,000
was key for and after that, I checked what the value is updated and it was successfully updated.

176
00:11:46,000 --> 00:11:52,000
And now let me show you a few examples that are related to old maps that are implemented on the basis

177
00:11:52,000 --> 00:11:53,000
of hash tables.

178
00:11:54,000 --> 00:11:58,000
Imagine that we have some type called default product and default user.

179
00:11:58,000 --> 00:12:04,000
If you don't remember these types, they are from your previous homework about implementation of online

180
00:12:04,000 --> 00:12:04,000
store.

181
00:12:05,000 --> 00:12:06,000
Let me read map work.

182
00:12:06,000 --> 00:12:10,000
Use will be of type user and values will be of type product.

183
00:12:10,000 --> 00:12:14,000
I create the false user object and the full product object.

184
00:12:14,000 --> 00:12:16,000
Now let me put one entry to the map.

185
00:12:17,000 --> 00:12:24,000
Now imagine that in some other part of my program I retrieve user from the database or receive user

186
00:12:24,000 --> 00:12:30,000
information from the front end and I create the new Java object, but with the same state for my John

187
00:12:30,000 --> 00:12:31,000
Smith user.

188
00:12:31,000 --> 00:12:38,000
And after that I want to get product objects for this user from the map by my user key I receive now

189
00:12:39,000 --> 00:12:41,000
known how hash tables work.

190
00:12:41,000 --> 00:12:45,000
Can you understand why I receive now and why my product value is lost in my map?

191
00:12:46,000 --> 00:12:49,000
Post the media for a second and try to answer this question.

192
00:12:50,000 --> 00:12:51,000
Let me answer this.

193
00:12:51,000 --> 00:12:55,000
This is because hash function is applied for the user object.

194
00:12:55,000 --> 00:12:57,000
But what value is returned?

195
00:12:57,000 --> 00:13:03,000
Schenkkan So you can see what has caused massive returns for my user object and user copy object.

196
00:13:03,000 --> 00:13:04,000
They're different.

197
00:13:05,000 --> 00:13:10,000
That means I have to override hash code message in user class so that it will constantly return the

198
00:13:10,000 --> 00:13:13,000
same hash code for equal users to save time.

199
00:13:13,000 --> 00:13:19,000
During the lesson I created one more implementation of user interface that overrides hash code and equals

200
00:13:19,000 --> 00:13:19,000
method.

201
00:13:19,000 --> 00:13:20,000
Let's look at it.

202
00:13:21,000 --> 00:13:24,000
So here you can see that I have hash code and equals method overridden.

203
00:13:25,000 --> 00:13:26,000
How to override method.

204
00:13:27,000 --> 00:13:29,000
Personally, I use Eclipse for that.

205
00:13:29,000 --> 00:13:37,000
In most of the cases I press hotkeys alz shift as in case you forgot hotkeys just press mouse right

206
00:13:37,000 --> 00:13:41,000
click source and find here generate hash code and equals.

207
00:13:42,000 --> 00:13:45,000
Eclipse asks whether I need to override this method one more time.

208
00:13:45,000 --> 00:13:48,000
Taking into account I already have this method.

209
00:13:48,000 --> 00:13:54,000
I will click here to show user interface of eclipse here can you can choose fields that you want to

210
00:13:54,000 --> 00:13:56,000
use for equals and has called massive.

211
00:13:57,000 --> 00:14:02,000
Please pay attention that you will now want to use static fields in equals and hash code methods.

212
00:14:03,000 --> 00:14:04,000
Can you understand why?

213
00:14:04,000 --> 00:14:09,000
Because static fields are related to the class itself rather than to object of this class.

214
00:14:10,000 --> 00:14:16,000
And in case you will use static fields for calculating hash code or equals, these masses wouldn't meet

215
00:14:16,000 --> 00:14:19,000
the requirements which we talked about in this lesson.

216
00:14:20,000 --> 00:14:24,000
Here's one checkbox that I usually check is to use methods from object class.

217
00:14:25,000 --> 00:14:28,000
This makes our methods written in a different way.

218
00:14:28,000 --> 00:14:32,000
That takes less lines of code than without using objects class.

219
00:14:32,000 --> 00:14:36,000
There is also one another checkbox that you might want to select.

220
00:14:36,000 --> 00:14:38,000
Sometimes I will show you the difference.

221
00:14:39,000 --> 00:14:42,000
So here you just click generate and methods are generated.

222
00:14:42,000 --> 00:14:45,000
I will cancel because I already generated masjids.

223
00:14:46,000 --> 00:14:48,000
Here's a hash code method.

224
00:14:48,000 --> 00:14:51,000
Optionally, you can investigate how hash method is implemented.

225
00:14:52,000 --> 00:14:58,000
You can see that I call hash method on object class and pass all fields that I want to be taken into

226
00:14:58,000 --> 00:15:00,000
account to compute the hash of the object.

227
00:15:01,000 --> 00:15:04,000
Now, multiple invocation of code method and different objects.

228
00:15:04,000 --> 00:15:09,000
All the channels, the same integer value here is our equals method.

229
00:15:09,000 --> 00:15:14,000
At the beginning we check equality by references if references as a same religion.

230
00:15:14,000 --> 00:15:19,000
True, if objects that we pass to the method is now, then we return false.

231
00:15:19,000 --> 00:15:25,000
Now I get class of the current object and get class of the object that we got from that argument.

232
00:15:26,000 --> 00:15:31,000
And potentially you can use here instance of operator, for example, in the case it is not critical

233
00:15:31,000 --> 00:15:36,000
for you that objects are created on the basis of different classes, sometimes for use.

234
00:15:36,000 --> 00:15:42,000
The fact that two different objects are compatible with type and have the same state is enough to tell

235
00:15:42,000 --> 00:15:43,000
that both of them are equal.

236
00:15:44,000 --> 00:15:47,000
But it depends personally in most cases.

237
00:15:47,000 --> 00:15:53,000
I use that clause here, but I have to warn you that you might want to use instances of operator here

238
00:15:53,000 --> 00:15:55,000
to check compatibility and that is also fine.

239
00:15:56,000 --> 00:16:03,000
After this check, we can cast object to the current class type and check for quality field by field

240
00:16:03,000 --> 00:16:09,000
in case all state from the other object is the same as state of this object, then very trencher.

241
00:16:10,000 --> 00:16:15,000
Can you understand now why the set of fields that we use in equals and hash code MassArt should be the

242
00:16:15,000 --> 00:16:16,000
same?

243
00:16:16,000 --> 00:16:17,000
Great.

244
00:16:17,000 --> 00:16:20,000
Let's get back to our demo file now.

245
00:16:20,000 --> 00:16:26,000
We create the object of our type that overrides hash code and equals method, we put it.

246
00:16:26,000 --> 00:16:29,000
As a key in our map and map it against our product.

247
00:16:30,000 --> 00:16:36,000
After that, I read the same copy of our user analysis that we did previous time, and now I want to

248
00:16:36,000 --> 00:16:38,000
get my product by the key.

249
00:16:38,000 --> 00:16:39,000
And here it is.

250
00:16:40,000 --> 00:16:45,000
I managed to retrieve product from a map because my hash table was managed to find the right market

251
00:16:45,000 --> 00:16:46,000
and the value in it.

252
00:16:47,000 --> 00:16:52,000
Now imagine that for some reasons, the state of the user is changed in the database.

253
00:16:52,000 --> 00:16:59,000
Let's imagine that John Smith decided to change his email address and now he uses new email domain.

254
00:16:59,000 --> 00:17:03,000
Lets retrieve that product again and then consult with him.

255
00:17:03,000 --> 00:17:06,000
Now, can you understand why?

256
00:17:06,000 --> 00:17:11,000
Because in our case, we use all fields of user to compute hash code, as you remember.

257
00:17:12,000 --> 00:17:16,000
And when email was changed, hash code also was changed.

258
00:17:16,000 --> 00:17:23,000
But the object that is used for key in the map still uses the old email and definitely our hash map

259
00:17:23,000 --> 00:17:28,000
can't find the right market was our key to return a product.

260
00:17:28,000 --> 00:17:32,000
That's why it is recommended to use immutable objects for keys.

261
00:17:32,000 --> 00:17:34,000
What are immutable objects?

262
00:17:34,000 --> 00:17:39,000
The objects, the state of which is never changed after its creation.

263
00:17:39,000 --> 00:17:42,000
The example of a mutable type is strength.

264
00:17:42,000 --> 00:17:48,000
This object is designed in the way that there is no any method that can change state of the original

265
00:17:48,000 --> 00:17:50,000
object after its creation.

266
00:17:50,000 --> 00:17:55,000
The intention to replace method, for example, it should replace some characters with others.

267
00:17:56,000 --> 00:18:01,000
You would notice that this method returns new objects of string, but not modifies the previous one.

268
00:18:02,000 --> 00:18:08,000
In case you use mutable keys and hash map, pay extra attention that the key is stable, but usually

269
00:18:08,000 --> 00:18:10,000
is a string or integer.

270
00:18:10,000 --> 00:18:11,000
Objects are used as keys.

271
00:18:12,000 --> 00:18:18,000
I believe we learned a lot about hash tables and the last thing that I would like to share with you

272
00:18:18,000 --> 00:18:21,000
is to show you how to sort my bike keys and values.

273
00:18:22,000 --> 00:18:26,000
Here is a separate file with the examples of maps stored in the same hash map.

274
00:18:26,000 --> 00:18:30,000
Object is created here with a similar data set as we had in previous example.

275
00:18:31,000 --> 00:18:36,000
Now, if you remember from the last about map interface we have comparing bickie and comparing Vivarium

276
00:18:36,000 --> 00:18:43,000
assets in our entry type to search entries in the map, you already know that list interface has search

277
00:18:43,000 --> 00:18:44,000
method, musical action.

278
00:18:44,000 --> 00:18:47,000
Nawzad interface has sought MassArt.

279
00:18:47,000 --> 00:18:54,000
That's why we have to use the latest object and create variable of this type parametrized by entry type.

280
00:18:54,000 --> 00:18:57,000
That in turn is parametrized by integer and string.

281
00:18:57,000 --> 00:19:01,000
Probably you notice that I use just entry word in this file.

282
00:19:01,000 --> 00:19:05,000
That is because I have a statement here for map entry time.

283
00:19:06,000 --> 00:19:11,000
After that I create a real E object and pass to the constructor and reset of my map.

284
00:19:12,000 --> 00:19:19,000
Now I can search elements in this list and enter type has default method that returns comparator to

285
00:19:19,000 --> 00:19:20,000
source entries by key.

286
00:19:21,000 --> 00:19:27,000
I want to shuffle elements before Soden to make sure that certain work is expected to shuffle elements

287
00:19:27,000 --> 00:19:33,000
and your special message from collections class with utility methods nonwar will review this class in

288
00:19:33,000 --> 00:19:34,000
the separate lesson.

289
00:19:35,000 --> 00:19:39,000
Right now I will use only one method from that class for the demo purposes.

290
00:19:40,000 --> 00:19:44,000
I print shuffled elements to console to prove that they are not sorted.

291
00:19:45,000 --> 00:19:49,000
After that, I saw the elements and print source at least to the console.

292
00:19:49,000 --> 00:19:54,000
Let me run the program and here you can see that all elements and least assorted now.

293
00:19:55,000 --> 00:19:55,000
Awesome.

294
00:19:56,000 --> 00:19:57,000
Just want to pay attention.

295
00:19:57,000 --> 00:20:04,000
This sort only four keys that implements comparable interface if your key doesn't implement comparable

296
00:20:05,000 --> 00:20:11,000
Xeros overloaded version of comparing by key method that also takes Comparator as an argument.

297
00:20:11,000 --> 00:20:15,000
And we already had separate lesson and homework regarding Khambatta.

298
00:20:15,000 --> 00:20:17,000
That's why I will not stop on this.

299
00:20:18,000 --> 00:20:22,000
In case you would face issues, let me know and write in comments.

300
00:20:22,000 --> 00:20:24,000
I will help you to source my keys.

301
00:20:24,000 --> 00:20:30,000
It is also super easy to create an object of three map and add entries to that map.

302
00:20:30,000 --> 00:20:32,000
To put all entries to three map.

303
00:20:32,000 --> 00:20:36,000
I use special constructor that takes any map as an argument.

304
00:20:36,000 --> 00:20:40,000
We are going to have separate lesson about sorted map and three map.

305
00:20:40,000 --> 00:20:46,000
But you already familiar with key features of this interface and class from the map Iraqi lesson and

306
00:20:46,000 --> 00:20:47,000
take into account.

307
00:20:47,000 --> 00:20:49,000
We are talking about sorting of elements.

308
00:20:49,000 --> 00:20:56,000
It was dimension to the map here and last but not least for today, is how to search your map by values.

309
00:20:56,000 --> 00:20:58,000
We again shuffle entries before sorting.

310
00:20:59,000 --> 00:21:02,000
After that, we use comparator that can be created by entry type.

311
00:21:03,000 --> 00:21:06,000
And again, this comparing by value method has overloaded versions.

312
00:21:06,000 --> 00:21:12,000
That takes Comparator as an argument that is in case your values don't implement comparable.

313
00:21:13,000 --> 00:21:16,000
And here we print list of entries sorted by value.

314
00:21:17,000 --> 00:21:23,000
You remember that to convert an array of entries to map, we have a special method of entries, but

315
00:21:23,000 --> 00:21:24,000
they use it efficiently.

316
00:21:24,000 --> 00:21:26,000
We have to understand functional from.

317
00:21:26,000 --> 00:21:30,000
Ramin Anjelah, so conversion looks something like this.

318
00:21:30,000 --> 00:21:36,000
This is one of the options I showed you that just to make you understand that I remember everything

319
00:21:36,000 --> 00:21:40,000
and I want to separate lessons in the way you would understand.

320
00:21:40,000 --> 00:21:41,000
Amerson Don't worry.

321
00:21:41,000 --> 00:21:44,000
We will cover the topic separately in other lessons.

322
00:21:45,000 --> 00:21:48,000
Right now, I want to recap what we have learned today.

323
00:21:49,000 --> 00:21:52,000
In this lesson, we learned how hash tables work.

324
00:21:52,000 --> 00:21:58,000
Now you know how to override equals and hash code masset and water requirements exist for these methods.

325
00:21:59,000 --> 00:22:01,000
Today, we had a lot of practice with Hashmat.

326
00:22:02,000 --> 00:22:05,000
You main message and how to work with Hashmat.

327
00:22:05,000 --> 00:22:11,000
Also, we learned what immutable objects are and understood why immutable objects and good keys for

328
00:22:11,000 --> 00:22:12,000
our maps.

329
00:22:12,000 --> 00:22:17,000
And at the end of the lesson we learned how to search Mambi keys and Beverley's.

330
00:22:17,000 --> 00:22:20,000
I believe this was extremely fruitful lesson.

331
00:22:20,000 --> 00:22:22,000
Thanks a lot for your attention.

332
00:22:22,000 --> 00:22:24,000
See you in the next lesson.