[PPT] - 1 Collection architecture (cont.) Generic utility methods Map PowerPoint Presentation

SLIDE 1

1

Java Collection: Data structure framework

Background

access

implemented as an object-oriented framework – currently only "basic data structures sufficient for most needs" – sets, linked lists, arrays, and maps

– linked vs. sequential allocation, and hashing vs. sorted search trees

Interfaces of the collections framework

Collection architecture

and polymorphism

framework, and it enables user-defined extensions

– Collection

LinkedHashSet – SortedSet implemented by TreeSet

SLIDE 2

2

Collection architecture (cont.)

LinkedHashMap – SortedMap implemented by TreeMap

– Iterable: provides the method iterator () – Iterator: hasNext (), next (), and remove () – ListIterator: add (), set (), hasPrevious (), previous (), nextIndex (), etc..

skeletons for implementations – apply the Template Method pattern

Generic utility methods

kind of collection public static <E> boolean contains (Collection <E> c, Object obj) { for (E e : c) if (e.equals (obj) ) return true; return false; }

. .for (it = c.iterator (); it.hasNext (); ) { e = it.next ();. .

Using object-oriented collections

and separately create them as concrete collections: Set <String> set = new HashSet <String> (); set.add ("first"); set.add ("second"); int n = set.size (); // n is 2 assert set.contains ("first");

class or interface that can do the required job

Design of Collection framework

conflicting requirements: – easy to learn and convenient to use – as general as possible: dynamic / flexible / immutable, etc. structures – idiot-proof with complete run-time checks, and – as efficient as hand-coded algorithms

– Java cannot express and enforce constness at compile time – Java generics involves no run-time type info

SLIDE 3

3

Design of framework (cont.)

performance and errors

providing very general and concise interfaces

requirements and pure conceptual modelling – for example, interfaces have so-called optional

e.g., Iterator.remove () – a called forbidden optional operation throws UnsupportedOperationException (unchecked) – thus, constant views on collections are supported (only) by run-time checks

Design of framework (cont.)

is-a violation, at the conceptual level – the general object-oriented substitution principle: "operation that expects an instance of a supertype must also accept an instance of a subtype" does not hold here

– you should (generally) avoid applying these techniques in the design and interfaces of your

Overview: Collection

duplicates are (in principle) allowed – List is a sequentially ordered set of values – values in a List are ordered by position and can be identified by integer indices (0..)

– Set provides otherwise identical interface to Collection but allows no duplicates – values in a Set are not necessarily ordered or sorted

values

Overview: Map

Map is an "associative table" of key-value pairs

V oldValue = map.put (keyObject, newValue)

value = map.get (keyObject) For example, Map <String, V> map = new HashMap <String, V> (); map.put ("first", x); map.put ("second", y); map.put ("third", x); assert map.get ("first").equals (x); V v = map.remove ("first");

SLIDE 4

4

Overview: SortedMap

values – either by natural order given by the object class,

interface, or use a Comparator object

Views into collections

considered to be Collections

– Map.Entry provides methods: getKey (), getValue (), and setValue (v) – however, no getEntry (key) is provided (vs. C++ STL) - Entry is an interface, only

Proxy design pattern [Gamma et al, p. 207]

Views into collections (cont.)

i.e., not synchronized for concurrent access – this avoids unnecessary overheads

methods are synchronized or not (as usual)

separate synchronized views, created by a call: Collections.synchronizedX (X c), where X can be Collection, List, Map, Set, SortedMap, or SortedSet

Views into collections (cont.)

call: – Collections.unmodifiableX (X c)

algorithms: searching and sorting, etc.

have been fitted into the framework – however, the legacy classes are synchronized, and thus involve a substantial overhead

SLIDE 5

5

Collections and iterators

similar general behaviour: // implementation-dependency here only: Collection <E> coll = new LinkedList <E> (); // use through abstract interface: coll.add (element); ... Iterator <E> iterator = coll.iterator (); while (iterator.hasNext ()) { E element = iter.next (); // .. do something with element } ...

Using iterators

Iterator that can be used to traverse and possibly modify the collection: while (iter.hasNext ()) . . .

– if hasNext () returns false, then calling next () will throw (unchecked) NoSuchElementException

Advancing an iterator

Using iterators (cont.)

in the data structure – note: C++ containers use a different strategy: iterators are (abstract) pointers to elements

related to that position – iterator.remove () removes the element returned by the last next () – note that next () must be called (at least once) before each removal

SLIDE 6

6

Collection services

Iterator iterator () int size (); boolean isEmpty () boolean contains (Object v) boolean containsAll (Collection <?> c) boolean equals (Object other) boolean add (E element) boolean addAll (Collection <? extends E> c) boolean remove (Object element)

Collection services (cont.)

. . . boolean removeAll (Collection <?> c) void clear () boolean retainAll (Collection <?> c) Object [ ] toArray () <T> T [ ] toArray(T [ ] a) // may allocate bigger

E [ ] array = ... List <E> list = Arrays.asList (array) // a proxy can be used to create a fixed-size list backed by the specified array (changes "write through" to the array)

Collection services (cont.)

to indicate whether the operation really modified the data structure – e.g., remove (obj) returns true if a maching (equals) object was removed – note that iterator's remove returns void (as does ListIterator)

services, see the API or the textbook, pp. 85 - 93

The List Interface

// pos means position index 0..size list.add (pos, obj) list.addAll (pos, aCollection) list.get (pos) list.set (pos, obj)

ListIterator <E> iter = list.listIterator () ListIterator <E> iter = list.listIterator (fromPos)

SLIDE 7

7

The List Interface

. . . pos = list.indexOf (obj) pos = list.lastIndexOf (obj) sublist = list.subList (from, beyond) // get view

– is backed by this list, so non-structural changes are reflected in the original list, and vice-versa – supports all of the optional list operations supported by the backing list – becomes undefined if the backing list is structurally modified in other way than via the proxy

ListIterator

iter = list.listIterator (fromPos);

while (iter.hasPrevious ()) . . .

iter.add (obj) iter.set (obj) pos = iter.nextIndex () pos = iter.previousIndex ()

ListIterator (cont.)

sequential data structure – the iterator represents a position between two elements; or at beginning before all others (0);

current position, i.e., before the next element – if previous () is called after add, the new element is returned – so, calling add repeatedly puts elements in the exact order they are given – increases by one nextIndex and previousIndex