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 archieve order-by-title report up and running, you’re informed that more information about each item in the archive is going to be collected—and that it is going to vary depending upon the type of music item. (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: the number of tracks on the media, a positive integer, and 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: the label (which company distributed the record), a string of at least 1 character, and 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 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 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 MusicArchive.txt (which is provided to you in the ZIP file 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 returnig three.
Music items, of course, still exist, and all music items share some data (accession number, title, and media code). But it is now also the case that items on diferent media (with different media codes) 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 derive 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.
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. As before, the details of writing to and formatting the lines of the index file have been encapsulated in the class IndexFile, which has already been written and is being made available to you. Its methods are documented in MusicArchive.txt.
What has changed is that the IndexFile method writeItem() also prints out the supplemental information. Each media class has a method getSupplementalInfo() that returns a String of the supplemental data already formatted for printing on the report; writeItem() calls getSupplementalInfo() to get that string and display it in the appropriate place on the report. The format of the supplemental information is up to you; make it easy to read!
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, there are classes that can be used as is from the previous assignment; in particular, Bucket and MusicList. These two classes are provided to you as class files, and documented in MusicArchive.txt. Some methods in MusicItem and MusicManager also can be left unchanged from the previous assignment, since they are not affected by the presennse of additional music information; feel free to reuse your code from Lab Assignment 4 in this assignment.
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 is in the ZIP archive for this assignment. You should also test your program on other test lists you put together, in the manner described in the previous assignment.
As usual, to help you get started, we’ve prepared a number of Java skeleton programs for you. Download Lab5.zip to obtain them, along with the documentation and the test music file. Do look over the provided code carefully to get a good feel for what the various classes accomplish, and particularly how the various subclasses of MusicItem work together to deal with multiple media types.
In every file in which they appear, replace all spaces marked // your code goes here with your own Java code to produce a complete, correctly working program.
You will be required to complete one or more of the following methods: