Issue: As with any program, there is a need to put data into storage and retrieve it later. This is often called input/output or IO for short. Typically, this is to some file, but it could also be to a database, which also uses files, but we don’t interact with the files directly. The issues are how to store the data, that is in what form, and how should it be accomplished. Design patterns and object oriented design suggest that the method and form should be decoupled from the actual classes containing the data, as much as possible. Naturally, the classes containing the data will have to be aware of the object doing the actual storage, and probably have to implement one or more interfaces in order for them to be able to communicate.
Discussion: My first attempts at IO were based on several assumptions. One was that the record containing the data would best know how to save the data, and second was that overridding the toString() method was a terrific way to write the data to a text file. Both were very incorrect. After looking at some IO code written by others I realized that to decouple was a very good idea. I also realized that using toString() was pretty dumb, because it didn’t allow for any other type of storage except for a text file.
There are several ways to store the data. The aforementioned text file and database, but serialization and XML are other possibilities. My original concept was to use a delimited text file to store the data. This comes from my background in sed, awk, and perl. Although I’ve programmed in C and Visual Basic extensively, and dabbled in C++ and assembly. There are several benefits to delimited text. One is that it can be directly edited, if necessary, and it doesn’t use much space on disk. Now in today’s computers, disk space is not much of an issue, but having something in clear text I believe is an advantage.
The database option is actually a very good one except for its major drawback, which is that I would have to include and support the database to use. That creates additional headaches that I just don’t want to bother with. So, I rejected the database idea. Using serialization, which is built into Java, is good, but this program has many objects within many other objects. For example, a Member will appear in a Team, a Series, an Award, and a Treasury object. If I serialize each of those objects, I suspect that the Member object will be written (serialized) as part of them, thus it gets written four times. This seem a waste of space. Since serialized objects cannot be edited directly, I rejected this method.
The XML option is also a good one, but with two drawbacks. One is that it requires a lot of storage space as each element has much information, such as the element name and class, repeated many times. It is also much more complex, in my mind, to write the code to perform the IO. XML files are text, and so can be edited directly, but that doesn’t offset the drawbacks, so I rejected this format as well.
In order to be sure I created a basic type of object to do the storing and retrieving, I wanted it to be capable of performing its job for any of the formats discussed above. In order to do this I had to teach myself XML, database, and serialization techniques, and develop a rough version of the IO object for each. This was done, and they are the SerializedIO, XMLIO, and DBIO classes, which with the DelimitedFileIO object, rounds out the formats discussed.
I wanted to come up with a name for my basic object, actually it is an interface, which was unique, simple, and somewhat descriptive. Since I was moving something (data) from one point to another, came up with Conveyor, Mover, and others. Since I was going to be developing a specialized version for each format I wanted something that, and came up with Shovel. There are many kinds of shovels; snow, coal, garden, depending on what you are trying to move. The same is true here. So that is my name.
Conclusion: A shovel object will be used to convert the data in an object, normally a Record, using the desired format, to and from a storage location.