Assignment 8: Third Time’s a Charm – Three Trios, part 4

Due dates:

• Code given to customers: Sunday, Nov 24 by 11:59pm

• Implementation: Wednesday, Dec 4 at 8:59pm

• Self-evaluation: Thursday, Dec 5 at 11:59pm

• Peer-evaluation: Thursday, Dec 5 at 11:59pm

1 Purpose

In this assignment you will experience some effects of your design decisions, and practice working with implementations not written by you. Specifically, you will be integrating views and strategies implemented by your classmates.

2 Mechanics

Each group has been assigned two other groups: “providers” and “customers.” You must request code from your provider group: you will be emailed their names and email addresses. You should expect to need to email them a few times this week, as you may find issues with their code that you cannot address or repair by yourselves.

Similarly, your “customer” group will email you for your code. You are expected to spend some time supporting your customer group.1A small number of you may have your code used by two customer groups, because not everyone submitted sufficiently-completed code that could be used by other groups.

If you do not receive customer code by Sunday 11:59pm, email your instructor immediately!

3 Code Exchange

The code you will share will be constrained to the following:

• Your model interface(s), if any. This includes your main model interface, and other interfaces in the model package. It might include enums; it should not include implementation classes.

• Your view interface(s). This includes all your view interfaces, features interfaces, player-action interfaces, and other interfaces in the view package.

• Your controller interface(s), if any.

• Only your interactive view implementations (i.e. the main view implementations and any other supporting classes from the view package)

• Your README file

• A screenshot of the UI of your game.

You are not allowed to share or receive model implementations: the interfaces should be enough. You may exchange helpful implementation notes, but not actual code. If there is a need to know the implementations of certain classes from your model package and if those classes do not implement explicit interfaces, it likely means the coupling is tighter than it needs to be. If this is the case for the code that you share with your customer group, you will need to correct it and send the customers updated code. You can expect the same customer service from your provider group. (Note: you may have implemented simple value-classes, for instance to represent colors or points, that you consider to be part of your logical interface(s). You may share those value-classes with your customers. If you aren’t sure whether a particular class has too much functionality in it to be considered a value-class, assume that it isn’t and should not be shared.)

4 Intended Outcomes: what you must do

There are four outcomes that you must accomplish in this assignment:

• Make the views provided to you work with your code. You are not expected to write any tests for this. Use the provided view for displaying Player 2. Make sure to clearly document your new command-line options in your README, so graders know how to run your game.

• Retain the working features of your own views from previous assignments: i.e., you are not allowed to make changes in your code that make the providers’ code work, but break your own views or strategies. In particular, the command-line arguments from the previous assignment should continue to work, and Player 1 should continue to use your view implementation and your strategies.

• Write a comprehensive and constructive critique of the code given to you.

• Write a review of your experience.

Additionally, update your README file to clearly document which features of the provided views you were able to get working, and which ones you were not — this way, the graders will know what to expect when grading your code.

If there are features you could not adapt from the provider’s code and you justify why you could not adapt that code, you will not lose points. Being able to justify why an adapter is not possible also shows mastery over adapters. Make sure to leave the attempted adapters in the code to help prove your point.

5 Code issues

Since this assignment mixes your code with that of your providers, you may face the situation where you have interfaces or classes with the same name, in the same packages. Therefore, you should refactor your providers’ code to live in the cs3500.threetrios.provider package (subdividing into model, view, controller and strategy packages within it as appropriate), while retaining the package structure of all your code. You should not change anything else about their code. Any and all edits to the providers’ code (except the above package refactoring) must come from the providers.

In general, if the views provided to you do not implement a feature that your views did (and your controller and model support) you are not responsible for changing the provided views to implement those features. Make sure you mention them in the critique below. Conversely if you get a view that implements optional features, you are not required to make them work with your model and controller. If required features are incomplete you can expect the provider group to make an effort to complete them, and conversely, you must make an effort to complete them for your customers. If for some reason you do not get repaired code or explanations from your providers and as a result you are not able the provided views work, be sure to mention this in your critique and README (see below).

6 Code critique

As customers of the providers’ code, you have the opportunity to praise, critique, comment upon, and suggest improvements to their code. In short, you should provide a code review of their code.

In that review, consider all the self-evaluation questions you have been asked during this course, and extrapolate from them the kinds of issues to examine. For example:

• How flexible are the interfaces you were given?

• How capable are the views?

• How convenient was it to reuse their code?

• How cleanly written and well-documented was their code?

• If you needed to request changes from them, what were they and why were they needed?

Write a short (3-4 paragraph) review of their code. Your review should have the following sections: Design critique, implementation critique, documentation critique, design/code limitations and suggestions on how to address them.

Please concentrate on writing a review that is honest, but constructive. The reader should be able to understand what was wrong, and how to correct it. Please avoid simply criticizing the code given to you with no suggestions on how to make it better. Similarly avoid blanket praise: every implementation has flaws or limitations! Most importantly, please be professional in your writing. In summary, write a review that you would not mind receiving and acting upon.

Name this file PeerReview.txt, and put it in the same directory as your README file.

7 Review of the experience

Submit a second, smaller review of your experience of this exercise. This review should include the following two aspects:

• What do you wish you had done differently in your design/implementation? Did you learn any lessons from the code given to you, or the updates you had to make for your customers?

• What was your experience like with your providers?

Name this file SelfReview.txt and put it in the same directory as your README file.

8 Grading standards

For this assignment, you will be graded on

• the coherence and thoroughness of your review of your providers’ code (i.e. you are not being graded on your providers’ code).

• the coherence and completeness of your critique of your experience.

• the quality and completeness of your final submission (i.e., the degree to which the provided views work successfully with your code).

You will not be graded (much) on the code you send to your customers. It will simply be style-checked, and worth a small portion of your overall Assignment 8 grade, to ensure that you submit something we can compare against your customers’ use of your code.

Your grade will generally not be affected by your customers’ review of your code. Your grade may be affected by your responsiveness (or lack thereof) and experience with your customers.

There will be two self-evals: a short one about the code you sent to your customers, and a longer one about the code you needed to write for this assignment. Make sure that you complete both. (Having two separate self-evals is necessary, so that you can tag lines in each submission correctly.)

9 What to submit

Submission of this project will be divided into two parts: the code you provided others, and the code you worked on.

• For HW8 – views:

  • Submit the final version of the files you sent your customers.

  • Submit a README explaining which files you changed for your customers, and why the changes were needed.

• For HW8 – implementation:

  • Submit all files necessary to make your code work (this includes your code and code from your providers).

  • Submit all the tests you’ve written (or completed) for assignments 5–7, assuming you can fit them under the limit. If not, explain in your README what tests you had to remove.

  • Submit your review of your providers’ code.

  • Submit your review of your experience.

  • Submit a README file summarizing which features you were able to get working successfully and which features do not work in your final submission.

  • Submit a JAR file (with extension .jar) file that can run your program. Reminder: your program should now support additional command line options to specify which provider's strategy should be used for player 2.

Please submit your homework to https://handins.ccs.neu.edu/ by the above deadline. Then be sure to complete your self evaluations by their due date.

1A small number of you may have your code used by two customer groups, because not everyone submitted sufficiently-completed code that could be used by other groups.