Chapter 10 20-35

20	Identify the similarities and differences between the Fox and the Rabbit classes. Make separate lists of the fields, methods and constructors, and distinguish between the class variables (static fields) and instance variables.	They each have the isAlive boolean field, the age integer field, a location field, a breeding age, a max age, a breeding probability, and a MAX_LITTER_SIZE field, which is the same name, but used differently in each class. Their constructors are primarily the same, except the fox class has the food level component in its constructor. As for methods, they have many in common such as IsDead(), giveBirth(), setDead(), incrementAge(), breed(), canBreed(), setLocation(), and getLocation(). Their run() and hunt() methods are similar in the sense that they move the instance, but are different in their purpose.
21	Candidate methods to be placed in a superclass are those that are identical in all subclasses. Which methods are truly identical in the Fox and Rabbit classes? In reaching a conclusion, you might like to consider the effect of substituting the values of class variables into the bodies of the methods that use them.	IsDead(), giveBirth(), setDead(), incrementAge(), breed(), canBreed(), setLocation(), and getLocation(). Those methods are absolutely identical as has been asked.
22	In the current version of the simulation, the values of all similarly named class variables are different. If the two values of a particular class variable (BREEDING_AGE, say) were identical, would it make any difference to your assessment of which methods are identical?	No because the class variable would still be the same. It would still serve the same purpose, and would have the same functionality, it will only produce different results with different actual parameters.
23	What sort of regression-testing strategey could you establish before undertaking the process of refactoring on the simulation? Is this something that you could conveniently automate?	What is regression testing?
24	Create the Animal superclass in your version of the project. Make the changes dicussed in the text. Ensure that the simulation works in a similar manner as before.	I'm constantly getting this error, I've been working on fixing it for a while, but I don't seem to see why it doesn't work:
25	How has using inheritance improved the project so far? Discuss.	There was no need for the code duplication that we had in the classes of Rabbit and Fox, and as a result the project is now more simplified, easier to use, and takes up less space.
26	Although the body of the loop in Code 10.6 no longer deals with the Fox and Rabbit types, it still deals with the Animal type. Why is it not possible for it to treat each object in the collection simply using the Object type?	If it were to treat each object in the collection using the Object type, theoretically, it could place anything into the collection, as almost everything is a sub-class of the Object class (except for primitive types). As a result we could potentially get unexpected and unwanted results.
27	Is it necessary for a class with one or more abstract methods to be defined as abstract? If you are not sure, experiment with the source of the Animal class in the foxes-and-rabbits-v2 project.	No, having an abstract method simply means that it would be excluded from any instance of that type, and that it would have to be overridden by one of the classes sub-classes if it has any.
28	Is it possible for a class that has no abstract methods to be defined as abstract? If you are not sure, change act() to be a concrete method in the Animal class by giving it a method body with no statements.	Yes it is. Being abstract would mean that no instance could be made from the given class; however, since it would have no abstract methods no method would have to necessarily be overridden in its sub-classes. This also means that it would be a super-class for one or more sub-classes, as creating an abstract class at the end of the hierarchy would be wasted code, and effort, since no instance of or relating to the class could be created.
29	Could it ever make sense to define a class as abstract if it has no abstract methods? Discuss this.	Yes it could, this is largely discussed above, but basically if a user simply doesn't want any objects being created from that class he would define it as abstract. This wouldn't necessarily mean that any methods would have to overridden as they would if the class had abstract methods.
30
31
32	Which of the other simulation classes do not need to be aware of whether they are specifically dealing with foxes or rabbits? Could they be rewritten to use the Animal class instead? Would there be any particular benefits in doing this?/P>	The field and location classes can use the abstract class of Animal which would benefit the project by having less code duplication.
33	Review the overriding rules for methods and fields discussed in Chapter 9. Why are they particularly significant in our attempts to introduce inheritance into this application?	They are significant because with the new idea of having abstract methods it is important to know how to override methods, because otherwise the subclasses of the abstract method's class will also unintentionally be made into abstract classes.
34	The changes made in this text section have removed the dependence (couplings) of the simulateOneStep() method to the Fox and Rabbit class. The Simulator class however, is still coupled to Fox and Rabbit, because these classes are referenced in the populate() method. There is no way to avoid this: when we create Animal instances, we have to specify exactly what kind of animal to create. This could be improved by splitting the Simulator into two classes: one class Simulator, which runs the simulation and is completely decoupled from the concrete animal classes, and one class, PopulationGenerator (created and called by the simulator), which create the population. Only this class is coupled to the concrete animal classes, making it easier for a maintenance programmer to find places where change is necessary when the application is extended. Try implementing this refactoring step. The PopulationGenerator class should also define the colors for each type of animal.>	Done, however, I can't see the purpose of this:
35	The canBreed() method of Fox and Rabbit are textually identical, yet we chose not to move them to the Animal class. Why is this? Try moving the methods from Fox and Rabbit and making them protected. Is there any way to make the resulting classes compile and, even if there is, does the resulting simulation work as it should? How can you tell?	No, because each class has its own value for the BreedingAge, field and moving it up would require one to be set for the Animal class even though the fox and rabbit breeding ages are not the same. Since there is no way to have a universal BreedingAge, since that would defeat the purpose of the simulation, it is safe to assume that the canBreed() method cannot be moved up in the hierarchy.