|
|
The Data Interface The Data interface represents a collection of patterns.
This interface is used by the rest of the JSOMap API for accessing the
data used by the SOM. The patterns can be stored in any data structure, as long as
they can be accessed by an integer index.
Figure 1.
UML diagram for the Data interface. The three methods specified by the Data interface allow
full access to the underlying patterns. The
set method is specified as optional, so that implementations do not have to be
mutable. Any class that stores patterns can implement the Data
interface. This means that by
implementing Data, a class used by a different system can provide Pattern views
of its data elements and can be used directly by the other JSOMap classes,
without having to copy its data elements into a JSOMap Data implementation. Generally, any implementation of Pattern should have a
corresponding subinterface of Data. This
subinterface should specify get and set methods for the Pattern implementation.
Referring to the subinterface of Data allows clients to be sure of the
type of pattern they are working with. Since JSOMap provides two concrete implementations of
Pattern, it specifies two subinterfaces of Data: DoubleData and IntegerData.
These interfaces extend Data and specify additional get and set methods
that refer to their corresponding Pattern implementations.
Figure 2. UML diagram for the DoubleData and IntegerData interfaces. Figure
3
below shows the concrete implementations of the DoubleData interface.
Notice that all of the implementations (except SynchronizedDoubleData)
use an instance of BasicDoubleData. BasicDoubleData
is an implementation of DoubleData that other classes can use to build a set of
DoublePattern instances. Using the
add method, other classes can add patterns one-by-one. Mainly, these other classes either retrieve patterns from
some source or generate new patterns in some way.
SynchronizedDoubleData just wraps another DoubleData object, and declares
all of its methods as synchronized (this makes SynchronizedDoubleData safe to
use by multiple threads).
Figure
3. UML diagram for the concrete implementations of DoubleData. Figure
4
below shows the concrete implementations of the IntegerData interface.
These implementations follow the same sort of design as the DoubleData
implementations. Figure 4. UML diagram for the concrete implementations of IntegerData.
|
Send mail to zcox@iastate.edu with
questions or comments about this web site.
|