Issue: When loading/saving data to a delimited file, XML file, or even possibly, databases, saving objects which contain other objects creates a problem. An object such as a Member may appear in several other Objects. It may appear in the Member list, a Team object, and an Award object, not to mention that the Member object references the associated Bowler object. When saving to certain files, only the ID should be saved, not the entire object. When loading, the ID must be loaded correctly as an ID or Integer, and then converted into a reference to the actual object. This means either the conversion upon loading must have access to the various object lists, or the conversion to the object must happen at a later time. When the containing object is stored using serialization, or in a object storing database, the issue probably doesn’t exist.
Discussion: My original solution to the problem with inter-list communication was to use an object that I named BowlingData. It was an object containing all of the lists. It also was passed to all of the lists in their constructors, so each list could communicate with any other list. This appears to be something like the Mediator pattern. I had hoped to eliminate this in favor of composition, for example, a League has members and teams, a team has members, etc. I was going to use the Observer pattern to communicate changes down to the appropriate responsible object (if team size changed in the League object). But the observer pattern can’t help the storage problem.
So I use a Mediator to allow access to the various lists of objects. If I put a reference to the Mediator into the conversion class (StringUtilities) then those methods can no longer be static. They must be static to allow access to it from anywhere in the program without creating an instance! So that option isn’t available. Note that before the Mediator can be useful, in any usage, the desired List must already exist!
A second option is to make the Mediator a Singleton, use a static getInstance() method to return the same object every time it is called, thereby getting around this problem. Each method in the conversion class which converts a string (ID) into the object (the type), will need to retrieve the instance of Mediator. While this is possible, it may be time consuming.
Another option is to automatically convert the ID value to an Integer, then convert the Integer ID value to the associated object through a method call at the List and Record level. The Mediator will be available to the List, so it can be passed down to each Record, and subsequently, down to each Tic to do the necessary conversion. This puts the conversion code into the Record/List, and not in the conversion class (StringUtilities).
Conclusion: My goal with the conversion class (StringUtilites) was to separate the methods required for loading from a particular kind of input (delimited file, XML file, database file) from the List and Record classes. Since this is still a valid and admirable goal, I believe the proper way to handle this is keep the entire conversion in the conversion class. Unfortunately, I’m making StringUtilities dependent on the Mediator. While this may prove time consuming, it best suits the desire to keep the conversion code separate from the List and Record classes. Conversion from the object to the ID upon saving is relatively easy. It is handled in the conversion class, so when a certain object, like a Member object, is encountered, the conversion method calls getID() and converts that to a String.
Still to be determined is whether I should use the Mediator to pass change notices down through the lists, or use the observer pattern.