CIS 636 Spring 2005       Assignment 4 – Object Oriented Programming in Java – Creating Classes               100 points

Assigned: 02/10/2005

Due: 02/17/2005 at the start of class 

You may work individually or in pairs for this assignment. But all work must be the work of the person/people whose name is on the code! If working in pairs, the individual contributions should be relatively equal. One possibility is to work together tonight, then finish separately (to avoid communication difficulties).

Main Assignment:

We are building some pieces of a simplified card game program. The pieces we are starting with are – a playing card class, a deck of cards class, a person class and a subclass of it for a player. I imagine that we would LATER build classes for a hand (of cards), and for a particular game, and could re-use what we are creating for other games (and in the case of Person, other applications as well).  You are to build the classes, and also write (a) main program (s) that will test out the capabilities of the classes (thoroughly).

The Card class should be able to keep track of the name of the suit and rank of the card – it would be nice if it used enumerated types.  It should provide constructors,  all necessary accessors – inspectors and mutators, so that data can all be declared as private. Mutators should protect against bad data getting into objects if necessary (if passing an enumerated type we may be able to avoid this).  The class should support versions of equals and toString appropriate to the class.

The Deck class should be able to keep track of an array of playing cards. It should provide constructor(s),  any necessary accessors – inspectors and mutators, so that data can all be declared as private. The default constructor should probably construct a typical 52 card deck. Additional methods should be provided to shuffle the deck, deal the top card, and report if the cards in the deck are exhausted (the deck is empty). The class may not need versions of equals and toString.

The Person class should be able to keep track of the person’s first and last name, address, and have some kind of ID. It should provide constructors,  all necessary accessors – inspectors and mutators, so that data can all be declared as private. The class should support versions of equals and toString appropriate to the class.

The Player class should be a subclass of Person. So far what I can think of to keep track of would just be the player’s score. It should provide constructors,  all necessary accessors – inspectors and mutators, so that data can all be declared as private. The class should support versions of equals and toString appropriate to the class.

I encourage you to keep using my RedmondMsgInBasic and my RedmondMsgOut class for any needed input and output. Cancels on input dialog boxes will not be fully handled until we cover exceptions.

Hand in:

• Disk with an entire folder containing the correct folder structure, your file, any other of my classes that you use, and the corresponding Byte-code files.  I should be able to get into the IDE and run your program without any messing with your files and folders. So test what you are handing in, even if you already tested it on a hard drive or wherever.
• Print out of your code.  Make sure you change the print options in the IDE so that comments show up (Ask me about this in class)

To avoid needless long waits, I recommend working on this on the c: drive, then upon completion, copying it to the a: drive, testing it there, creating an extra backup for yourself, then deleting it from the c: drive.

Miscellaneous:

· Your Player class doesn’t need to hold cards, later if we create a Hand class, the player will hold a hand. For testing purposes, you could put in an array of cards (IF YOU WANT TO; you don’t have to).

· I can’t promise you that we will end up finishing this project, because weekly assignments are designed to address specific topics, and the topics needing to be addressed may not fit with what is left to do to create a card game. However, do your work under the assumption that you will be using it in the future – be robust, document, etc.

· MAKE SURE YOUR PROGRAM WORKS! (i.e. more than just removing compile errors).  Make your class as robust as possible in preparation for future use.

· Make sure that your main demonstrates that your methods work.

· Put YOUR NAME, and e-mail address and date in comments at the beginning of the program.

· Also, comment any significant code to document it (each method, each loop, each if, and each significant calculation should have a comment. In particular, each method needs to have a JAVADOC compatible comment).

· Indent code following standard conventions (indent to show that something is “inside” or “part of” the preceding code (e.g. inside if’s or loops, or statements continued on a new line).  The IDE should handle this if you hit ENTER and move on to the next line (If you make changes, you may need to TAB to make things right).

· Name your variables meaningfully, to describe their use in the program.

· For now (until we cover exceptions), we won’t catch invalid values that are the wrong type (e.g. letters where numbers are needed).