Storage of associated logical relationship data

As a container, map can store key-value pairs, so that we can quickly find the corresponding values (this is the associated logical relationship data ). However, if we want to not only store the logical connections between objects, but also perform more operations through their corresponding relationships, for example, each of our students, they all have their corresponding student IDs. They were not sorted at the time of storage, and they do not have any rules, what we want is a list of students whose student IDs can be sorted in the natural order. How should we store them in the first place? Now I have two solutions here: encapsulate the student object, which encapsulates the Student name and student ID data and then stores it in a list of objects, you can use the corresponding method of list to perform operations. The other is our map storage. Although it is indeed convenient for us to query, if we want to sort by key, we need to retrieve the key first. To be honest, it is very troublesome, first, use a normal version:

 
Set keys =Map. keyset ();If(Keys! =Null) {Iterator=Keys. iterator ();While(Iterator. hasnext () {object key=Iterator. Next (); object Value=Map. Get (key );}}
 

We can see that the keyset () method is used here. This method can map the set view of the key, in addition, any operation on this set will directly affect the original key, so you must pay attention to it when using it. It supports the removal of elements. The corresponding ing relationships are removed from the ing through the iterator. Remove, set. Remove, removeall, retainall, and clear operations. It does not support the Add or addall operation. Because the ing operation will affect the original key, if we do need to delete it, we will convert it into an array more often, like this: string [] keyset = map. keyset (). toarray (New String [0]); so that our removal operation will not affect the original key. This kind of processing method must be kept in mind. Any direct operations on containers are dangerous. We need to find the indirect layer for operations.

We noticed that the above method only maps the key, so we still need to use the get () method. However, it is not required if it is entryset (), because it maps the collection view containing key-value.

Set entries =Map. entryset ();If(Entries! =Null) {Iterator=Entries. iterator ();While(Iterator. hasnext () {map. Entry entry=(Entry) iterator. Next (); object key=Entry. getkey (); object Value=Entry. getvalue ();}}
 

It still needs to be used through iterator, but this time we must forcibly transform it to map. entry, which is equivalent to an object that encapsulates key-value. You can use getkey () and getvalue () to retrieve the corresponding key and value, in addition, we have more operations because it is an object and more methods. In terms of efficiency, the latter is faster and easier to use. Therefore, the latter is the first choice. However, this method is actually the first method to encapsulate objects. If you only store this relationship and perform a few operations, we can choose to encapsulate the object method, but if we need to query a large amount of data based on the key value, we need to use map.