Definition:  This is the abstract Collection which will hold Record subclasses.  Each subclass will have special methods unique to that implementation. 

A crucial issue is keeping the Collection in a sorted state.  The Java implementations for sorted Collections only sort when an element is added to the Collection.  Since the Record elements will be edited at some point, if the editing would change the sort order, the Collection won’t know it, and the sort order will be lost.  The only way to keep the sort order is to remove an element (Record) from the Collection, then add it back in after the editing is done.

There must be an iterator which can move in both directions in a normal (ie. not Java) fashion, and possibly wrap around at each end.  Thus a call for next() must provide the first element if at the end, and a call to previous() at the first element will return the last element.  By normal, I mean that unlike the Java ListIterator and Iterator classes, moving between next() and previous()  will return a different element than the current one.

The Store must be able to provide an array, in sorted order, of the Records for JList purposes. 

The sorted order of each Store will be different.  In some cases, like Teams, the team number determines the sort order.  For ContestDates, the sort will be on the date.  For Bowlers and Members, the sort order will be based on the name.  If two Records have the same name, then either the nickname, or the address, or as a last case, the ID value of the Record will be used.  No two Records in a given Store are to have the same ID number.

The Java Collection framework has three basic kinds of Collections; Set, List, and Map.  The Map is based on a Key and Value pair, which doesn’t apply here.  The List allows duplicate elements, but also infers an index positional sequence.  I don’t need that here.  The Set seems apprpriate, because it has only unique elements, which the Record’s will be, based on the ID value.  However, the only Java SortedSet may not provide the iteration and sorting characteristics I need.

Issue:  One issue is when to save any changes to storage.  If changes are made to one of the Record objects, the data will have to be written out to the storage (File).  Because I’m using a delimited file, the entire file must be re-written, however unchanged Record objects can simply be copied from the existing file, without having to save each Tic, and perform the necessary conversions again.  Since writing the file will take time, it is best if it is only done when necessary.  Since any editing changes will only be held in memory, until written out, if the power should fail or the computer experiences a serious problem, those changes would be lost.  So, writing as soon after the changes are made would be best.  I’ll have to come up with a compromise.

The second issue is the maintaining a sort order while iterating through the collection.  Java has only one SortedSet, which is a TreeSet.  While this is a Navigable set, having to remove a Record and re-adding it, may cause problems when attempting to properly move forward and backward in the set.  I would like the forward and backward movement to be relative the the current value of the current Record, something the Java implementation does not provide.  In addition, I would like the set to wrap around at the top and bottom boundary conditions.  That is, go from last to first when moving forward, and first to last when moving backward.  Java has no such capability.

Variables:  

  Modifier Class Name Value
public Integer serializableVersionUID 1234567
  privateMediator mediator
privateString filename
privateShovel (DelimitedFileIO) shovel

Requirements:

  • Serializable - just in case
  • Observable - Maybe
  • new, to create a new instance.
  • StoreIO

Required Methods:

 
  • A no argument constructor.
  • toArray() to return a sorted array of the elements for JList.
  • The compare(Object, Object), compareTo(Object), and equals(Object) methods. (Comparable and Comparator)
  • Save() and Load() methods for saving/loading with a Shovel. (StoreIO)
  • Get a specific object using the ID.  The object may be in memory or need to be retrieved from a data store (file). (HasID)
  • A way to manage ID values, so a new unique one is assigned to new elements.
  • Provide a bidirectional "normal" iterator.
  • getFilename() for the accompanying Shovel to use.
  • Must be able to communicate with the Mediator
  • Must create, manage, and respond to Property Change messages with the Mediator