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.