This assignment gives further practice in code reuse, and has you apply simple abstract classes, abstract methods, inheritance and polymorphism to organize data.
Figures! Just as you get the music archive ordered-by-title report up and running, you’re informed that more information about each item in the archive is going to be collected, that it is going to vary depending upon the type of music item, and that it is to appear, labeled and nicely formatted, as part of the report. (By the way, this changing of specifications while a project is in development happens a lot in the world of programming.)
In particular,
First off, nothing about the current information, its format, or its order is changing; what is changing is that each music file item will have additional information after the media code, on the same line. The additional field or fields will be separated from the media code (and each other) by the same “; ” (semicolon followed by a space) delimiter used on the rest of the line. For example, a compact media music item would be
accession number; title; C; number of tracks; year released
If the item is compact media, two fields follow the media code: (1) the number of tracks on the media, a positive integer, and (2) the year the item was released, a positive four-digit integer starting with 19 or 20.
If the item is a record, two fields follow the media code: (1) the label (which company distributed the record), a string of at least 1 character, and (2) the speed at which the record is to be played, a positive two-digit integer that is usually (but not always) 33, 45, or 78.
If the item is a cylinder, one field follows the media code: the maker (manufacturer) of the cylinder, a string of at least 1 character.
If the item is on paper, one field follows the media code: the number of pages the item has, a positive integer.
The program is also to print the same counts to the console window, following the same format requirements, as was done in Assignment 4.
The input file given to you will still be a text file, called music.txt, with each item’s information on one line in the format described above. Each line will end, as before, with the standard PC end-of-line mark, a carriage return character followed by a line feed character.
Again, the music file will have been run though a testing program to ensure its format is correct and that its fields follow the specifications given for them. You can be confident that the music file will be in the correct format to be fed into your program. The MusicFile class has been revised so it properly processes the revised music file; it has the same routines as before. Again, the routines are documented, this time in the file MusicArchiveDoc.txt, which is provided to you in the Eclipse project for this assignment. The only difference is that MusicFile’s readItem() returns an ArrayList with as many cells as necessary to hold the item’s information, rather than always returning an ArrayList with three cells.
Music items, of course, still exist, and all music items still have an accession number, title, and media code. But now, items have additonal information that differs by the kind of media. To encapsulate this situation in a nice way, we still have the MusicItem class, which stores all information and methods that apply to all music types. Then, from MusicItem, we extended specialty classes, one for each media type, that contain (in addition to what is inherited from MusicItem) the fields and methods needed to store and manipulate the supplemental information particular to that kind of media. Read the comments in the MusicItem file for details on these extended classes.
Some of the supplemental information is conceptually numeric, for example, the number of tracks on a CD, but this information is encoded as a string in order for it to be placed in the music information String ArrayList. To obtain the numeric equivaluent of this encoded string, use the parseInt method, a static method in Integer that takes a string and returns its integer equivalent (or throws an exception if the string cannot be converted to an integer). For instance, to obtain the number of tracks on a CD from the music item's information array, you would say something like numberOfTracks = Integer.parseInt(item.get(NUMBER_OF_TRACKS_POSITION)).
The index is to be placed into a text file still called index.txt. It will have the information about each musical item on one line, nicely formatted, and be in alphabetical order by title. The IndexFile method writeItem() has been modified so it calls the method displaySupplementalInfo() , which returns a String of the supplemental data formatted for printing on the report; writeItem() plaes that information in the appropriate place on the report. The format of the supplemental information is up to you; make it easy to read.
As before, the details of writing to and formatting the lines of the index file have been encapsulated in the class IndexFile, which is being made available to you as a class file. Its public methods are also documented in MusicArchiveDoc.txt
The media category code constants are now in the MusicItem class.
All other aspects of the program are the same as before; all that changes is the input data and its appearance on the by-title report. So, the Bucket and MusicList classes can be used as is from the previous assignment, since they already meet this assignment’s requirements.. These two classes are provided to you as class files, and documented in MusicArchiveDoc.txt. Some methods in MusicItem and MusicManager also can be left unchanged from the previous assignment, since they are not affected by the presence of additional music information; feel free to reuse that code from Lab Assignment 4.
Archive personnel are still compiling the revised list of music, so you will have to test your program using test files. We’ve provided one for you, again called music.txt; it, too, is in the project file for this assignment. You should also test your program on other test lists you put together, in the manner described in the previous assignment.
The files discussed above, along with, as usual, a number of Java skeleton programs, are in the zipped Eclipse project file 21Lab5.zip. Using the same procedure that you followed previously, unzip the file and import this project into your Eclipse workspace. Do look over the provided code carefully to get a good feel for what the various classes accomplish, and particularly for how the various subclasses of MusicItem work together to deal with multiple media types.
Lab Exam 4 will be very similar, but perhaps not identical, to the program you have been asked to write for this assignment. The lab exam will ask you to complete one or more of the following methods: