Abstraction

Jag objects interact in very intricate ways: a solver may need to execute the image function of an operator ${\bf A}$ and add an update to the estimated solution ${\bf x}$.The solver, as well as its programmer, has no knowledge of the internals of ${\bf A}$ or ${\bf x}$.Obviously not every solver will work with every operator, nor will every operator be able to image every vector. It is important that a programmer and a compiler can easily verify if a set of objects will collaborate. A solver should also operate with as many operators and vectors as possible. Furthermore, a solver should not only collaborate with the appropriate existing operators or vectors, but with any appropriate operator or vector, even future ones.

We use Java's interfaces to separate solver, operator, and vector classes, despite their sophisticated interactions. Java interfaces, not unlike C++ virtual classes, define a set of method prototypes. Any class that implements an interface has to implement all the interface's methods. Any class that interacts with implementations of an interface can rely upon the fact that any particular implementation offers all the methods listed in the interface. Interfaces are Java's purest form of class abstraction.

We isolated Jag's most important interfaces in a separate package called Jam. These interfaces specify the methods expected from Jag's mathematical entities. For example, all the operators are derived from the interface jam.operator.Operator and therefore implement the interface method public Vector image(Vector d). Similarly, all Jam vectors are derived from an interface called jam.vector.Vector and, consequently, implement a method public void add(Vector vec2). As long as any implemented class, e.g., a solver, restricts itself to methods listed in Jam's interfaces, then such a class will find the methods it expects.