CSE143 Project 4 Mix 'n Match
or, Change Partners and Dance
| There is a separate turn-in form for submitting each of the projects. Click below to turn in your code. Use these forms for your final Deep project, too. | |
| Corrections, Clarifications, etc.
12/5 11:00am. Sharp eyes have already uncovered some
problems. The most annoying are a bunch of unnecessary methods in the
Calculator and TicTacToe packages (too many to list individually).
The Calculator files have been replaced already, Also, a set of compiled, runnable stubs for the Calculator classes are among the files. These will probably be updated without notice as better stubs or shallow implementations become available. There will also be such runnable implementations for the other projects. PS We haven't quite figured out yet how to make your compiled implementations available to one another. It will probably be something like the date file turn-in. |
New!
Classmate Classes. Please review the
README file before using them. All starting code as a .zip file The code includes:
Please keep this package structure. Any new files you create must go into one of the three project packages. |
Pick a model, a view, and a controller to implement. They must come from at least two different projects. Designate two of your choices as "shallow", and one as "deep".
General rules:
- For each application, there is a specified interface for each component. You must implement that interface, and you may not add any public methods, except the constructors specifically listed in the comments (unfortunately, constructors can't be officially specified in an Interface).
- There are also some naming and packaging requirements that relate mainly to making sure the components can be located and identified properly. You must follow any such requirements carefully.
- You will be allowed to create additional classes, but only within the same package, and clients will not know about them.
- You may also use any standard Java library classes, and any solution code from this quarter. All other code should be written by you.
- None of the components should perform actions which would keep the application as a whole from progressing.
- Y
our component doesn't "work" unless it works with any combination of (correct) components for that project.
For the shallow tasks: make a complete, runnable implementation. It does not have to be fancy, or use all the capabilities of the interface. In other words, you can make it as close to a stub as you wish, as long it minimally meets the specifications. (In the case of the more complex models, we may settle for even less than that.) For the deep task: it's your chance to show off and/or be creative. Make an implementation that lets you do both. The notes below apply mainly to the deep task, but you should read them all anyway.
For the model: Implement the interface completely. It should be robust enough not to crash, no matter what calls are made on it. When preconditions are violated, you are free to throw an (unchecked) exception, or to violate the postconditions or cause the application to terminate (of course, you might want to leave a trail so that anyone can see that it is clearly the client who was at fault!)
For the View: If you must implement a View for the project. The
constructor should take a reference to the Model. You must avoid any form of
user interaction. You should do nothing which blocks the other components from proceeding
(such as waiting or sleeping). You should not call any of the Model methods which change its state.
[Footnote: a more elaborate design would have the model interface partitioned into smaller parts,
with the view and controller functions separated.] Note: you are not required to implement
a graphical viewer. However, if this is your deep task, you probably do want to. In that
case, create your own JFrame so you won't have to share it with the Controller. Just as
a convention for ease of use, place your frame toward the left side of the screen, and try
not to take up more than half of the total screen real estate. This is just for courtesy,
not a hard requirement.
For the Controller: Your implementation will contain the main class for the entire project. In main (or better, in the constructor), you should create a model and a view, passing the model reference to the view. You can define any classes and methods you wish, but they all must be in the same package as your main class. The methods and classes you define will not be known to or used by the View or Model (you can't enforce that, of course -- it is a requirement on them, not on the Controller). Your program remains in control of the application. Any user input must be done at the initiation of the Controller. The Controller is not required to use all of the methods of the Model, nor is it required to do any user interaction, unless required by the application. If you use a GUI... see the notes above about the View GUI; place your JFrame towards the right of the screen.
Some mechanics: read through all the projects and make your selection. Tell us in writing (hardcopy) by Friday what your selections are. Expect the turn-in, testing, and grading procedures for the project to be somewhat different from the previous ones.Deadlines:
- Friday lecture Dec. 6: project choices.
- Tuesday evening, December 10: Electronically, shallow versions of all three components. For your designated two shallow components, this will be their final deadline. For the deep component, turn in at least a shallow, working version.
- Wednesday evening, December 11: Electronically, the final version of your deep component.
Please don't begin work until you have read these
instructions completely through, top to bottom, word for word. Then do the
same for the code in the Interfaces and starter code classes. (Asking on
bended knee )