The Observer pattern (also known as Listener, or Publish-Subscribe)
is particularly useful for graphical applications.

The general idea is that one or more objects (the subscribers) register
their interest in being notified of changes to another object (the publisher).
The subscribers can also change the state of the publisher, although this
is not obligatory (one might call these "active" observers, as opposed
to "passive" ones, which do not change the state of the publisher). Interfaces
are used to ensure that publishers and subscribers have only minimal knowledge
of each other.

When using Swing, there is a choice among using Observable
and Observer
, or one of the many XXXListener interfaces which apply to GUI components.

Although Observer is indeed an interface, Observable
is neither an interface nor an abstract base class: it's a concrete
class. This is very unusual. Almost all implementations of Design Patterns
define the important items as either interfaces or abstract base classes,
not as concrete classes.

Example

The CurrentPortfolio
class is a non-graphical class which encapsulates data regarding a set of stocks - a stock portfolio.
It's the central abstraction of its application, and a number of other classes need to interact with
it, both as active and passive listeners. Since it's a non-graphical class, it extends
Observable.
Note how it calls:

whenever its underlying data changes, informing its listeners of changes to the portfolio.

The FileSaveAction
class is an "active" Observer of the CurrentPortfolio: it both
reacts to changes in the CurrentPortfolio, and changes it. It reacts to CurrentPortfolio
in its update method, where it enables the action only when the CurrentPortfolio has unsaved edits.
When FileSaveAction itself is executed, on the other hand, its actionPerformed method
acts upon CurrentPortfolio by changing its state to "no unsaved edits".