View
218
Download
2
Tags:
Embed Size (px)
Citation preview
Design Constraints for a Standard Data Structures Library
● Used directly or indirectly by every programmer for everything within its scope
● Primitive in the mathematical sense: individual components designed to perform only a single role
● Invaluable and affordable to essentially every student and professional programmer
Design Constraints for a Standard Data Structures Library (con.)
● Convenient, efficient, and reasonably safe for common use
● Complete at what they do● Supportive of commonly-accepted
programming stylesBjarne Stroustrup, The C++ Programming Language (Special Third Ed.), Addison-
Wesley, 2000.
Forces between contradictory constraints
● Used directly or indirectly by every programmer for everything within its scope
● Primitive in the mathematical sense: individual components designed to perform only a single role
● Invaluable and affordable to essentially every student and professional programmer
● Convenient, efficient, and reasonably safe for common use
● Complete at what they do
● Supportive of commonly-accepted programming styles
Tradeoffs between Design Goals: How elaborate a Hierarchy?
Initial: Standalone Vector (Stack?!), Hashtable
JDK 1.2 Framework
Interfaces, Abstract Classes
Application-level Classes
JDK 1.5 Framework
A bit broader and deeper
Abstract Queue, Priority Queue
Rejected Purer Alternatives
Could avoid “OperationNot Supported”
Cost: Greatly increased footprint and complexity
Design Patterns:Resolving Tensions between Data Structures Library Design Goals
Iterator
Template Method
Support for Concurrency
Enumeration vs. Iterator
● Elements elements()● boolean
hasMoreElements()● Object nextElement()
● Iterator iterator()● boolean hasNext()● Object next()● remove()
GOF “Implementation Issues”
● Who controls the iterator?● Who defines the iterator? Iterators
may need privileged access.● Using polymorphic iterators● Additional iterator operations?● How robust is the iterator?
JDK 1.5 foreach
Prior to JDK 1.5:
public boolean containsAll
(Collection c) {
for (Iterator itr = c.iterator;
iter.hasNext(); ) {
if (!contains(iter.next()) {
return false;
}
}
return true;
}
JDK 1.5:
public boolean containsAll
(Collection c) {
for (Object o : c) {
if (!contains(o) {
return false;
}
}
return true;
}
Who defines the iterator? Iterators may need privileged access.
public abstract class AbstractList<E>
implements List<E> {....
private class Itr implements Iterator<E> {... }
private class ListItr implements ListIterator<E> {..}
}
Dual Hierarchy:
Collection
Iterator<E>
LinkedHashMap<K, V>
CollectionCollection
ArrayList<E>
LinkedHashIterator<E>
ListIterator<E>
Additional iterator operations?
Iterator<E>
next()hasNext()remove()
List Iterator<E>
previous()hasPrevious()nextIndex()previousIndex()set()add()
Using Polymorphic Iterators
● Iterator Collection.iterator() Factory methodpublic interface Iterable<T>
Iterator<T> iterator();
}
public interface Collection<E> extends Iterable<E> {
Iterator<E> iterator(); .....
}
● No reset() ... Just acquire a new iterator()!● Garbage collection targets providing better
support for cheap, short-lived, new objects
How robust is the Iterator?public abstract class AbstractList<E>
implements List<E> { ....
private class Itr implements Iterator<E> {
int expectedModCount = modCount;
.....
final void checkForComodification() {
if (modCount != expectedModCount)
throw new ConcurrentModificationException();
}
....
}
AbstractList depends on polymorphic Iterator<E> operations
public abstract class AbstractList<E> implements List<E> { .... public boolean addAll(int index, Collection<? extends E> c) { boolean modified = false; Iterator<? extends E> e = c.iterator(); while (e.hasNext()) { add(index++, e.next()); modified = true; } return modified; }...}
Collections depend on polymorphic equals(), compareTo()
public abstract class AbstractList<E> implements List<E> { .... public int IndexOf(Object o) { .... ListIterator<? extends E> .... }... public int lastIndexOf(Object o) { .... ListIterator<? extends E> .... }...}
HashMap, HashSet Arrays.sort .... equals() .... .... compareTo() ...
Support for ConcurrencyVector, Hashtable made ALL methods synchronized JDK 1.2 Decorator for synchronized, unmodifiable collections:
Map<String, Circuit> ckts = Collections.SynchornizedMap(
new HashMap<String, Circuit>);java.util.concurrency:
Application-level Tools:
Concurrent HashMap, ConvurrentLinkedQueue
Futures
Executor
Core Mechanisms Available:
Exchanger
SynchronousQueue
CyclicBarrier
Semaphore