Project 2 - Implementation

Project 2 - Implementation
CSC/CPE 203 
This programming assignment is the complement of the Project2 Design Document assignment. The
general task was already explained; this assignment description provides additional details and tips for
the programming aspects of the redesign.
Objectives
• To be able to read and understand java code and be able to evaluate the cohesion of the class
structure in existing code
• To be able to implement interfaces and use them to improve cohesion in a project design
• To be able to translate your code design from UML into refactored Java code
• Specifically, for this assignment, in the actual java code, introduce appropriate classes in order to
remove the need for enumerated types and for any other classes that contain methods that do
not support the primary role of instances of that class
• To be able to make design changes to a large code base and have the code still work
Task Overview
You must identify those classes with low cohesion and then split these classes into separate classes
exhibiting high cohesion. Since each of these new classes will introduce a separate type, you may need
to "root" them at a single type (as defined by an interface) to satisfy Java's type checking rules. You
will not introduce any additional classes beyond those used to improve cohesion (e.g., you will not use
inheritance in this pair of assignments). This refactoring is quite likely to increase the amount of code
through the duplication of some methods; this is expected and ok at this time.
Based on the original source code, there are likely two categories of classes with low cohesion. The first
category consists of those classes that depend on ActionKind or EntityKind. The second category
depends on your final distribution of the methods in the original Functions class.
• Kind: The original source code uses ActionKind and EntityKind to allow
each Action instance and each Entity instance to play one of potentially many roles (this
mimics a tagged union). You are to eliminate these *Kind classes (enums) by
splitting Action and Entity into multiple new classes.
• Other: Review all of the classes with a focus on cohesion. Does a class contain data that is not
used by all instances of the class (i.e., each "kind" uses only subsets of the data)? Does a class
contain methods that do not support the primary role of instances of the class (e.g., static
methods that are used to create instances or parse files, but that are not actually part of the
functionality provided by the instances)? For example, this is the time to make sure that the
parse* methods for example find a better home.
As before, you are encouraged to develop both the UML design document and the code refactoring at the
same time. You are further encouraged to implement the refactoring incrementally so that your refactored
program executes properly at each step.
Source Code Refactoring
Your refactoring should mirror the work done for your design document (UML diagram) augmented with
feedback from your instructor.
Your refactoring must not add or remove any program functionality. The resulting program must
work as before.
Tips on Refactoring Methods
You can use the compiler (on the command-line or in the IDE) to help you with your refactoring. In
particular, as you introduce interfaces, the compiler will report attempts to use methods not supported by
the specified type. The existence of such errors may indicate missing methods for an interface or, more
likely, attempts to treat a group of objects more generally than should be supported (i.e., not all of them
implement the desired operation).
As part of your refactoring, you will be eliminating the *Kind classes. This is desired to allow each new
class to directly implement a single role, but has the unfortunate side-effect of eliminating a simple check
of an object's "kind". This check is used, for instance, when searching for the nearest Fish to a octo.
Consider the following tips.
• For a class that is being split into multiple class, change the original class into an interface
declaring no methods. Compile the program to determine all uses of this interface (the method
invocations will trigger compiler errors). Now determine which of these methods must be
supported by all instances of this interface and which should be supported via additional
interfaces.
You can copy the original class to, and change all references to, NameTmp and declare it
to implement the new interface so that most of the code will continue to compile.
• For those methods that are not logically part of the primary interface defined in the prior step,
introduce new interfaces and change the necessary variable declarations to use the new types.
• A check for the "kind" of a referenced object can, for now (though we will address this later), be
replaced by a use of instanceof. Use this cautiously; certainly, instanceof is not needed to
check the type of this.
• In the case that a *Kind value was passed as a parameter to another method (and then
compared within), you can do the following.
o Change the parameter type from the specific *Kind to Class (this is a type where each
instance represents properties of a specific Java class).
o Instead of passing a *Kind value, use .class to get the object associated with the
desired Java class (e.g., String.class gives the Class object describing
the String class).
o Change the comparison to use the isInstance() method on the Class object,
passing to this method the object to be checked.
Assignment Submission
Your submission must include all source files (even those that were unchanged). Your grader should be
able to build your project based on the files submitted. (You do not need to submit the image files, the
image list, or the world save file.) An explicit list of files is not given because you are creating new files for
this assignment, so verify that you have submitted everything properly. Remove files from your repository
that are no longer needed for your project (e.g. EntityKind.java).
Rubric
Implementation part worth 60% of your grade. Submit your updated UML diagram and a Zip file that
includes all your java files in Canvas.
 Points
1) Run without error 10
2) Run correctly 10
3) Refactoring 40
a. Interfaces 15
b. Classes 25