Goals

• Introduce Application
• Find Commonalities and Refactor Into New Abstract Class
• Clean Up Ugliness
• Don't Change Output

Needs

• Abstraction.jar

Background

Many times during the design of a project, there comes a point when multiple classes do much of the same work. Code is duplicated, scaling becomes inefficient and abstraction is needed. Java allows for clever design practices to help pull out common code into an Abstract class which then is common to any class that extends it.

This design decision can reduce technical debt and should be refactored immediately when you realize code and behavior is common between classes.

//TODO

You are given an Abstraction.jar file which contains 3 class objects and a driver (shown below). Since we will be refactoring, I want you to Import this .jar so you have access to its fully editable code.

• com.putable.labs.lab6.Wolf.java
• com.putable.labs.lab6.Eagle.java
• com.putable.labs.lab6.Rabbit.java
• com.putable.labs.lab6.PredatorPreySimulator.java

The application is a fight simulator for interactions between animals in the wild. The driver works as follows:

1. Populate the Animal Kingdom with instances of different animals
2. Choose 2 animals at random and run the "fight formula"
3. Print out each animal, their genus name and their weight and say who would win in the wild

Your job is 3-fold:

1. Find commonalities in code/behavior between the com.putable.labs.lab6.Wolf, com.putable.labs.lab6.Eagle and com.putable.labs.lab6.Rabbit. Refactor into a new Abstract class which each animal then extends.
2. Put the storage of the animal's "genus" name in the abstraction. It should NOT be the responsibility of the caller to hard code it.
3. Remove all instanceof and object casts in the code. The abstraction should clean this code up exponentially.

Some Rules:

• Don't add parameters to the constructors of each concrete class.
• Don't change the content of the ConsumptionType enum. However, feel free to move it around.
• The format of the output must stay the same.
• Don't change the fight formula; it's highly scientific.
• You can either leave the class variables as private and use getters/setters to access them, or you can change them to protected. However, make sure you know what it means to be protected instead of just doing it because Eclipse recommends it to fix a compiler error.
• Feel free to play around with different populations of the animal kingdom.

Turn in an Abstraction.jar file containing your newly refactored/abstracted com.putable.labs.lab6.Wolf.java, com.putable.labs.lab6.Eagle.java and com.putable.labs.lab6.Rabbit.java and com.putable.labs.lab6.PredatorPreySimulator.java. The .jar must also contain your Abstract class, named however you see fit. Everything should live in the com.putable.labs.lab6 package. Make sure to turn in the java source files otherwise you will get a 0.

The Abstraction.jar should be turned in using the online interface by 11:59:59 PM of your lab day.