Shulou(Shulou.com)06/03 Report--

This article focuses on "case analysis of Iterator pattern in Java". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "the case analysis of Iterator pattern in Java"!

Let's first briefly discuss a root interface Collection, then analyze an abstract class AbstractList and its corresponding Iterator interface, and carefully study the implementation principle of iterative subpatterns.

The source code version discussed in this article is JDK 1.4.2, because JDK 1.5 uses a lot of generic code in java.util, so let's talk about version 1.4 code to simplify the problem.

The root interface Collection of the collection class

The Collection interface is the root type of all collection classes. One of its main interface methods is:

Boolean add (Object c)

The add () method adds a new element. Note that this method returns a boolean, but the return value does not indicate whether the addition was successful or not. If you read doc carefully, you can see that Collection states that if a collection refuses to add this element, an exception must be thrown for any reason. The meaning of this return value is whether the content of the collection has changed (that is, whether the number of elements, location, etc.) has changed after the execution of the add () method, which is implemented by the concrete class. That is, if a method goes wrong, an exception is always thrown; the return value simply indicates whether the content of the Collection has changed since the method was executed.

Similarly, there are:

Boolean addAll (Collection c)

Boolean remove (Object o)

Boolean removeAll (Collection c)

Boolean remainAll (Collection c)

The Object [] toArray () method is simple to convert the collection to an array and return it. The Object [] toArray (Object [] a) method is a bit complicated. First, the returned Object [] is still an array of all the elements of the collection, but the type and parameter an are of the same type, such as executing:

String [] o = (String []) c.toArray (new String [0])

The resulting o actual type is String [].

Second, if the size of the parameter a cannot hold all the elements of the collection, a new array will be returned. If the parameter an is large enough to hold all the elements of the collection, it still returns a, but the contents of an are populated with the elements of the collection. In particular, it is important to note that if the size of an is more than the number of elements in the collection, all the parts after an are set to null.

The last and most important method is iterator (), which returns an Iterator (iterator) that is used to iterate through all the elements of the collection.

Implementing traversing collections with Iterator pattern

The Iterator pattern is a standard access method for traversing collection classes. It abstracts the access logic from different types of collection classes, thus avoiding exposing the internal structure of the collection to the client.

For example, if you are not using Iterator, the way to traverse an array is to use an index:

For (int item0; I

To access a linked list (LinkedList), you must use a while loop:

While ((e=e.next ())! = null) {. E.data ().}

The client of the above two methods must know the internal structure of the collection in advance, the access code and the collection itself are tightly coupled, so it is impossible to separate the access logic from the collection class and the client code, and each collection corresponds to a traversal method. Client code cannot be reused.

To make matters worse, if you need to replace ArrayList with LinkedList in the future, the original client code must be completely rewritten.

To solve the above problems, the Iterator pattern always traverses the collection with the same logic:

For (Iterator it = c.iterater (); it.hasNext ();) {

The secret is that the client itself does not maintain a "pointer" to traverse the collection, and all internal states (such as the current element location, whether there is the next element) are maintained by Iterator, and this Iterator is generated by the collection class through factory methods, so it knows how to traverse the entire collection.

The client never deals directly with the collection class, it always controls the Iterator, sends it commands such as "forward", "backward", and "take the current element", and can traverse the entire collection indirectly.

First, take a look at the definition of the java.util.Iterator interface:

Public interface Iterator {

Boolean hasNext ()

Object next ()

Void remove ()

}

The traversal can be done by relying on the first two methods, and the typical code is as follows:

For (Iterator it = c.iterator (); it.hasNext ();) {

Object o = it.next ()

/ / the operation of a pair of o.

}

In JDK1.5, the above code is also syntactically simplified:

/ / Type is a specific type, such as String.

For (Type t: C) {

/ / the operation of a pair of t.

}

The specific type of Iterator returned by each collection class may be different. Array may return ArrayIterator,Set, SetIterator,Tree may return TreeIterator, but they all implement the Iterator interface, so the client does not care what kind of Iterator it is, it only needs to get the Iterator interface, which is the power of object-oriented.

Analysis of Iterator Source Code

Let's take a look at how AbstracyList creates Iterator. First, AbstractList defines an inner class (inner class):

Private class Itr implements Iterator {

...

}

The definition of the iterator () method is:

Public Iterator iterator () {

Return new Itr ()

}

So the client doesn't know the true type of Iterator it gets through Iterator it = a.iterator ();.

What we care about now is how the Itr class, declared private, traverses the AbstractList:

Private class Itr implements Iterator {

Int cursor = 0

Int lastRet =-1

Int expectedModCount = modCount

}

The Itr class relies on three int variables (and an implicit reference to AbstractList) for traversal, cursor is the location of the element on the next call to next (), and the first call to next () returns the element with an index of 0. LastRet records the location of the last cursor, so it is always 1 less than cursor.

The variable cursor and the number of elements in the collection determine hasNext ():

Public boolean hasNext () {

Return cursor! = size ()

}

The method next () returns the element with index cursor, and then modifies the values of cursor and lastRet:

Public Object next () {

CheckForComodification ()

Try {

Object next = get (cursor)

LastRet = cursor++

Return next

} catch (IndexOutOfBoundsException e) {

CheckForComodification ()

Throw new NoSuchElementException ()

}

}

ExpectedModCount represents the expected modcount value, which is used to determine whether the collection has been modified during traversal. AbstractList contains a modCount variable with an initial value of 0, and modCount adds 1 each time the collection is modified (calling methods such as add,remove, etc.). Therefore, if the modCount remains unchanged, it means that the contents of the collection have not been modified.

Itr initializes the modCount variable of the collection with expectedModCount, and then detects the value of modCount where necessary:

Final void checkForComodification () {

If (modCount! = expectedModCount)

Throw new ConcurrentModificationException ()

}

If the modCount is different from the value initially recorded in the expectedModeCount, the content of the collection has been modified, and a ConcurrentModificationException is thrown.

This ConcurrentModificationException is RuntimeException, so don't capture it on the client side. If this exception occurs, there is something wrong with the coding of the program, and you should carefully examine the code instead of ignoring it in catch.

However, there is no problem calling Iterator's own remove () method to delete the current element, because the values of expectedModCount and modCount are automatically synchronized in this method:

Public void remove () {

...

AbstractList.this.remove (lastRet)

...

/ / reset the expectedModCount after calling the remove () method of the collection:

ExpectedModCount = modCount

...

}

To ensure that the traversal process completes smoothly, you must ensure that the contents of the collection are not changed during traversal (except for the remove () method of Iterator), so the principle for ensuring that traversal is reliable is to use the collection only in one thread, or to synchronize traversal code in multiple threads.

Finally, a complete example is given:

Collection c = new ArrayList ()

C.add ("abc")

C.add ("xyz")

For (Iterator it = c.iterator (); it.hasNext ();) {

String s = (String) it.next ()

System.out.println (s)

}

If you replace the ArrayList of the first line of code with LinkedList or Vector, the rest of the code can be compiled without changing one line, and the function remains the same. this is the principle of abstract programming: minimal dependence on concrete classes.

At this point, I believe you have a deeper understanding of "instance resolution of Iterator schema in Java". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.