#6 Avoid package private visibility

[Jürgen Failenschmid]

There are several members that have package private
visibility. This makes it cumbersome to use the
member's class as parent class in other packages.

For example, GraphTraversal has a package private
graph attribute but no access methods. A subclass of
GraphTraversal in another package cannot access the
graph attribute, and has to resort to define its own
graph attribute.

It is generally better to use protected visibility
instead of package private, especially if the owning
class is abstract.

[Jesus M. Salvo Jr.]

Logged In: YES
user_id=15433

Sorry for the very late response. Had to deal with reality
first.

Anyway, the graph attribute in GraphTraversal is already
not private, but protected. ( No visibility specified,
which defaults to protected ).

[Jürgen Failenschmid]

Logged In: YES
user_id=358315

A member without visibility keyword defaults to "package
private" visibility, NOT "protected". In other words, the
above mentioned members should use keyword "protected".

To test an example, try to subclass GraphTraversal in a
separate package and access graph.