Map.Entry interface in java

2019-02-23 07:13发布

java.util.Map.Entry as I know is a public static interface in java.util package that returns collection view of a map but as far now I am confused with the static interface and as it is Map.Entry is it an inner interface if so how do we have inner static interfaces in java

Look people I am confused Please help me in any possible way you can.

6条回答
Ridiculous、
2楼-- · 2019-02-23 07:22

The definition of Entry happens to live inside the definition of Map (allowed by java). Being static means you don't need an instance of Map to refer to an Entry.

It's easiest to show how to use Map.Entry by an example. Here's how you can iterate over a map

Map<Integer, String> map = new HashMap<Integer, String>();

for (Map.Entry<Integer, String> entry : map.entrySet()) {
    Integer key = entry.getKey();
    String value = entry.getValue();
    // do something with key and/or value etc
    // you may also alter the entry's value inside this loop via entry.setValue()
}
查看更多
欢心
3楼-- · 2019-02-23 07:24

Inner interfaces are implicitly public and static.

You can have inner interfaces as follows :

1.   interface A {
             .....
             .....
             interface B {
                          ....
                          ....
             }

     }



2.   class A {
              ....
              ....
              interface B {
                            ....
                            ....
              }

     }

You can access the above inner interface(B) by A.B where A is a class or an interface according to the above two cases.

For example,

class x implements A.B
{
         ....
         ....
}
查看更多
来,给爷笑一个
4楼-- · 2019-02-23 07:31

Yes, it's an inner interface of the Map interface.


   /**
     * A map entry (key-value pair).  The <tt>Map.entrySet</tt> method returns
     * a collection-view of the map, whose elements are of this class.  The
     * <i>only</i> way to obtain a reference to a map entry is from the
     * iterator of this collection-view.  These <tt>Map.Entry</tt> objects are
     * valid <i>only</i> for the duration of the iteration; more formally,
     * the behavior of a map entry is undefined if the backing map has been
     * modified after the entry was returned by the iterator, except through
     * the <tt>setValue</tt> operation on the map entry.
     *
     * @see Map#entrySet()
     * @since 1.2
     */
    interface Entry<K,V> {
        /**
     * Returns the key corresponding to this entry.
     *
     * @return the key corresponding to this entry
         * @throws IllegalStateException implementations may, but are not
         *         required to, throw this exception if the entry has been
         *         removed from the backing map.
     */
    K getKey();

        /**
     * Returns the value corresponding to this entry.  If the mapping
     * has been removed from the backing map (by the iterator's
     * <tt>remove</tt> operation), the results of this call are undefined.
     *
     * @return the value corresponding to this entry
         * @throws IllegalStateException implementations may, but are not
         *         required to, throw this exception if the entry has been
         *         removed from the backing map.
     */
    V getValue();

        /**
     * Replaces the value corresponding to this entry with the specified
     * value (optional operation).  (Writes through to the map.)  The
     * behavior of this call is undefined if the mapping has already been
     * removed from the map (by the iterator's <tt>remove</tt> operation).
     *
         * @param value new value to be stored in this entry
         * @return old value corresponding to the entry
         * @throws UnsupportedOperationException if the <tt>put</tt> operation
         *         is not supported by the backing map
         * @throws ClassCastException if the class of the specified value
         *         prevents it from being stored in the backing map
         * @throws NullPointerException if the backing map does not permit
         *         null values, and the specified value is null
         * @throws IllegalArgumentException if some property of this value
         *         prevents it from being stored in the backing map
         * @throws IllegalStateException implementations may, but are not
         *         required to, throw this exception if the entry has been
         *         removed from the backing map.
         */
    V setValue(V value);

    /**
     * Compares the specified object with this entry for equality.
     * Returns <tt>true</tt> if the given object is also a map entry and
     * the two entries represent the same mapping.  More formally, two
     * entries <tt>e1</tt> and <tt>e2</tt> represent the same mapping
     * if<pre>
         *     (e1.getKey()==null ?
         *      e2.getKey()==null : e1.getKey().equals(e2.getKey()))  &amp;&amp;
         *     (e1.getValue()==null ?
         *      e2.getValue()==null : e1.getValue().equals(e2.getValue()))
         * </pre>
     * This ensures that the <tt>equals</tt> method works properly across
     * different implementations of the <tt>Map.Entry</tt> interface.
     *
     * @param o object to be compared for equality with this map entry
     * @return <tt>true</tt> if the specified object is equal to this map
     *         entry
         */
    boolean equals(Object o);

    /**
     * Returns the hash code value for this map entry.  The hash code
     * of a map entry <tt>e</tt> is defined to be: <pre>
     *     (e.getKey()==null   ? 0 : e.getKey().hashCode()) ^
     *     (e.getValue()==null ? 0 : e.getValue().hashCode())
         * </pre>
     * This ensures that <tt>e1.equals(e2)</tt> implies that
     * <tt>e1.hashCode()==e2.hashCode()</tt> for any two Entries
     * <tt>e1</tt> and <tt>e2</tt>, as required by the general
     * contract of <tt>Object.hashCode</tt>.
     *
     * @return the hash code value for this map entry
     * @see Object#hashCode()
     * @see Object#equals(Object)
     * @see #equals(Object)
     */
    int hashCode();
    }

For more information about interfaces, see the Interfaces tutorial and this Static Nested Interfaces article.

查看更多
smile是对你的礼貌
5楼-- · 2019-02-23 07:43

There isn't really anything to be confused about.

Yes, Java allows interfaces to be members of classes or other interfaces.

No, that does not mean anything special. It changes absolutely nothing about how you can use such an interface or what you can do with it.

It only changes the name of that interface and creates a strong conceptual link between it and its enclosing type. In this case, a Map.Entry represents an entry of a Map. The designers of the API apparently felt that it made sense to stress this connection by making it a member type.

查看更多
走好不送
6楼-- · 2019-02-23 07:45

Java allows nested interfaces. You can nest them into classes or interfaces. For instance, Map.Entry is a nested interface defined in the Map interface.

Map implementations (TreeMap, HashMap) provide private implementations of Map.Entry, which are not visible outside the class.

Bohemian's answer addresses how to use Map.Entry.

查看更多
我命由我不由天
7楼-- · 2019-02-23 07:48

Example:

public class Outer {
    public interface Bar {
        Bar get();
    }
}

Bar is a nested interface. Nested interfaces are static by default, so you could as well write:

public class Outer {
    public static interface Bar {
        Bar get();
    }
}

Now, what static in this context means is that the interface is a static member, i.e. a member of the class.

You can do this with classes as well:

public class Tree {
    private static class Node {

    }
}

Here, Node is even private, meaning it's only visible within Tree. So, what's the benefit of this? Why not make Node a public class? Because of better encapsulation. First, the Node is an implementation detail of the Tree, so you don't want it to be visible. Second, if you expose Node via a public API, some client (programmer) could use it in his code. Now, he has a hard dependency on this class. If at some point you want to change the representation of you Tree, and you change/remove the Node class, the client code's may break. And last but not least, your public API becomes smaller, which is also desirable.

So, when to use static member classes/interfaces? Mostly, if you build some sort of Composite object (like a Tree, or a Linked List) or when the class only makes sense in the context of the outer class.

查看更多
登录 后发表回答