Table of contents
Frameworks
A framework is a set of classes and interface types that structures the essential mechanisms of a particular domain.
An application framework is a framework for creating applications of a particular type.
Inversion of control in a framework signifies that the framework classes, and not the application classes, are responsible for the control flow in the application.
- An application framework supplies a set of classes that an application programmer augments to build an application, often by forming subclasses of framework classes.
- In an application framework, the framework classes, not the application classes control the flow of execution. This is called the inversion of control.
Applets as a Simple Framework
An applet is a Java program that runs inside a browser.
The applet package is a simple framework that demonstrates subclassing from framework classes and inversion of control.
To design an applet, you must write a class that extends the Applet. The following methods need to be overwritten.
- init: Called one, when the applet loads. Purpose: Initialize data structures and add user interface elements.
- start: Called when applet is first loaded and user restores the browser window. Purpose: Start or restart animation or other computationally intensive tasks.
- stop: Called when the user leaves the browser window or the browser terminates. Purpose: Stop computationally intensive tasks when the applet is not being viewed.
- destroy: Called when the browser terminates. Purpose: Relinquish any resources that were acquired during init or other processing.
- paint: Called when the applet window needs repainting. Purpose: Redraw the window contents to reflect the current state of the applet data structures.
The Collections Framework
The collections library is both a repository of common data structures and a framework for new collection classes.
A collection is a data structure that contains objects, which are called the elements of the collection. The collection framework has a number of interfaces for collections:
- Collection: the most general collection interface type.
- Set: an unordered collection that does not permit duplicate elements.
- SortedSet: a set whose elements are visited in sorted order.
- List: an ordered collection, elements accessible by integer index.
- Extra: Map: Associates one set of objects, called keys, with another set, called values.
Some common implementations of these interfaces are:
- HashSet: a set implementation that uses hashing to locate the set elements
- TreeSet: a sorted set implementation that stores the elements in a balanced binary tree
- LinkedList and ArrayList: implementations of the List interface.
The two fundamental interfaces however, are:
- Collection: Class that can hold elements in some way.
- Iterator: Mechanism for visiting the elements of the collection.
A class that is added to the collections hierarchy can benefit from the mechanisms that the framework provides. Like static methods for finding the maximum or minimum element in a collection.
The collection interface is divided up in two main interfaces: Set and List.
Set
The set interface adds no methods to the collection interface. Because implemented sets behave differently on add and equals methods, there needed to be a parent interface to designate extending children as sets.
List
The list interface makes no difference between a sorted collection and a unsorted collection. It also gives no garantuee about how efficient operations are in different implementations. The drawback of this becomes apparant if we consider the LinkedList class, it has O(n) time for accesing an element by it's index.
Now let's take a look at the binarySearch method of the Collections class. It ensures O(log2(n) for a n sized collection if we want to search for an element.
This only holds when acces time is O(1), making the method useless for a LinkedList implementation even when the method is supposed to be usable for all List implementations.
To circumvent this problem, the interface RandomAcces was added to the Collection framework. It is used to tag a class as being able to acces a random element in O(1) time, it has no methods. (ArrayList implements RandomAcces, LinkedList does not)
<Image p. 332, figure 5>
Optional Operations
A view is an object of a class that implements one of the interface types in the collections framework, and that permits restricted acces to a datastructure.

In this example we construct a List from a String Array. This list has the extra methods such as the bulk addAll. But remember the restricted acces.
This List<String> will throw an UnsupportedOperationException if you use the add or remove method. This because an array cannot become larger or smaller. The drawback to this construct is that the compiler will give no errors while compiling, they will show up during runtime!
The Collection class method unmodifiableList returns a list that can be viewed, but not modified.
A Graph Editor Framework
The problem domain for our graph editor framework is the interactive editing of graphs that consist of nodes and edges.
An application that is based on the graph editor framework defines specific behavior for the nodes and edges.
The graph editor framework encapsulates those aspects that are common to all graph editing applications.
UI
Division of Responsibility
The framework programmer is responsible for generic mechanisms, whereas the application programmer needs to supply code that is specific to a particular application. A concrete graph class must enumerate all node and edge types for the given graph.
The prototype pattern teaches how a system can instantiate classes that are not known when the system is built.
Pattern: Prototype
Context
- A system needs to create several kinds of objects whose classes are not known when the system is built.
- You do not want to require a separate class for each kind of object.
- You want to aoid a separate hierarchy of classes whose responsibility it is to create the objects.
Solution
- Define a prototype interface that is common to all created objects.
- Supply a prototype object for each kind of object that the system creates.
- Clone the prototype object whenever a new object of the given kind is required.
<Image p. 337>
Example
| Name in Design Pattern | Actual Name |
| Prototype | Node |
| ConcretePrototype1 | CircleNode |
| Creator | The GraphPanel class that handles the mouse operation for adding new nodes to the graph |
Say we have a SimpleGraph that uses Nodes and Edges. Nodes and Edges can be interfaces in this setting. CircleNode or BoxNode can be implementations of the Node interface and DottedEdge or OpaqueEdge can be implementations of the Edge interface.
Framework Classes
Enhancing the Graph Editor Framework

Comments