Data Structures and Algorithms in Java[1].pdf - Fulvio Frisone

• Computing a cycle in G, or reporting that G has no cycles.
The justification of Proposition 13.13 is based on algorithms that use slightly
modified versions of the DFS algorithm as subroutines.
13.3.2 Implementing Depth-First Search
As we have mentioned above, the data structure we use to represent a graph impacts
the performance of the DFS algorithm. For example, an adjacency list can be used
to yield a running time of O(n + m) for traversing a graph with n vertices and m
edges. Using an adjacency matrix, on the other hand, would result in a running time
of O(n 2 ), since each of the n calls to the incidentEdges method would take
O(n) time. If the graph is dense, that is, it has close to O(n 2 ) edges, then the
difference between these two choices is minor, as they both would run in O(n 2 )
time. But if the graph is sparse, that is, it has close to O(n) edges, then the
adjacency matrix approach would be much slower than the adjacency list approach.
Another important implementation detail deals with the way vertices and edges are
represented. In particular, we need to have a way of marking vertices and edges as
visited or not. There are two simple solutions, but each has drawbacks:
• We can build our vertex and edge objects to contain an explored field,
which can be used by the DFS algorithm for marking. This approach is quite
simple, and supports constant-time marking and unmarking, but it assumes that
we are designing our graph with DFS in mind, which will not always be valid.
Furthermore, this approach needlessly restricts DFS to graphs with vertices
having an explored field. Thus, if we want a generic DFS algorithm that can
take any graph as input, this approach has limitations.
• We can use an auxiliary hash table to store all the explored vertices and
edges during the DFS algorithm. This scheme is general, in that it does not require
any special fields in the positions of the graph. But this approach does not achieve
worst-case constant time for marking and unmarking of vertices edges. Instead,
such a hash table only supports the mark (insert) and test (find) operations in
constant expected time (see Section 9.2).
Fortunately, there is a middle ground between these two extremes.
The Decorator Pattern
Marking the explored vertices in a DFS traversal is an example of the decorator
software engineering design pattern. This pattern is used to add decorations (also
called attributes) to existing objects. Each decoration is identified by a key
identifying this decoration and by a value associated with the key. The use of
decorations is motivated by the need of some algorithms and data structures to
add extra variables, or temporary scratch data, to objects that do not normally
813