Assignment - iTunes Objects

An iTunes entry in music library is a descriptor that summarizes information about the tune that it describes. (It is not the actual tune, which is contained in a large music data file.) For each iTunes entry in your own music library file (which is in XML format, but we won't go there) there are between 20 and 50 fields -- i.e., members. If you were to look at the file on your system, you would find that the fields have names like Genre, Track ID, Name, Artist, Bit Rate, Sample Rate, Track Type, and so on.

We will consider a simplified iTunes class, that stores these iTunes entry objects, with only the following four members for each object:

-Name (the title of the song)

-Artist (the performing musician or group)

-Bit Rate (the number of kilobits per second that the iTunes object streams at or plays at -- higher for better quality, lower for smaller data file size)

-Total Time (the playing time of the iTunes object, represented in milliseconds, i.e., 36500 would stand for 36.5 seconds).

The assignment is to first create a class called iTunes that represents these four items, and provides solid protection for the fields. Then, the client, main(), will instantiate between three and six iTunes objects (some using default constructors and some using parameter-taking constructors), display them immediately, mutate many of their fields, and display them again to reflect the changes. Also, test both mutators and accessors, individually in a couple spot-tests of each (two mutator tests and two accessor tests).

The Program Spec

Class iTunes Spec - Private class instance members:

-String name - the title of the song. All legal strings should be between 1 and 80 characters.

-String artist - the performing musician or group. All legal strings should be between 1 and 80 characters.

-int bitrate - the number of kilobits per second. A legal value should be between 64 and 705.

-int totalTime - the playing time in milliseconds. A legal value should be between 1 second and 1 hour (expressed in milliseconds)

As stated in the modules, we never want to see a literal in our methods. So the class should have static members to hold values for the limits described above, as well as default values for any field that is constructed using illegal arguments from the client. These are put in the public static section.

Public class static constants (finals):

-MIN_BITRATE = 64

-MAX_BITRATE = 705

-MIN_STR_LENGTH = 1

-MAX_STR_LENGTH = 80

-MIN_PLAY_TIME = 1000

-MAX_PLAY_TIME = 1000*60*60

-DEFAULT_BITRATE = 64

-DEFAULT_PLAY_TIME = 1000

-DEFAULT_STRING = " (undefined)"

You should supply all of the following public instance methods:

-Constructors -- one that takes no parameters (sets values to default) and one that takes all four parameters.

-Accessors (get()s) and Mutators (set()s) for each instance member.

-String toString() - a method that returns a String which contains all the information of the iTunes object. This String can be in any format as long as it is understandable and clearly formatted. Two of the many possible formats for such a String for oneiTunesobject might be:

"Janiva Magness, You Were Never Mine, 276 seconds, 128k bits per second"

"Title: You Were Never Mine / Artist: Janiva Magness / Playing Time: 4 minutes 36 seconds / Bit Rate: 128k"

-void display() - an output method that sends the String returned by the toString() to the screen. display() can, alternatively, send the data directly to the screen on several lines in a different manner than toString(). It can also call upontoString() but prepend and append extra formatting for the console.

iTunes should be a class distinct from (and not contained within) your main class (which we call Foothill). However, you can and should defined it as a non-public class so it can reside in the same file, Foothill.java.

The Foothill main()

The client has been described, but to summarize, it should instantiate, display, mutate, and display again. It does not have to take any input from the user.

Other Testing

After the main section, confirm that your mutators correctly filter out and report bad arguments to the client by placing a couple mutator calls (not all of them) in if statements which print different messages depending on whether the mutator succeeded or failed. Also, demonstrate at least two different accessor calls to show that they work from main().