Java (and OOP in general) is highly touted for its use in writing extensible software. Class hierarchies let us add features to existing classes without editing the source code of the original classes: simply put the new features into a new class that extends the original. This lab explores how well this approach supports extensible-software construction.
For this lab to be effective, we have to simulate two aspects of real software practice:
We don’t know what extensions will be required in future.
Ideally, extensions can’t edit existing code. Often, you sell early versions of software and then offer upgrades or optional extensions with some sort of patch, rather than a whole new software release. Sometimes, you are creating a family of products and want to mix-and-match features.
To simulate the first, we have broken the problem description into several documents. Please don’t read ahead – it spoils the point.
To simulate the second, your answers to each new set of questions may not edit any of the classes you wrote for previous parts (with the exception of the Examples class for testing purposes). In other words, if you need to "add" code to a class, do it by extending that class with a new subclass. Do not add any variables, methods, or other edits directly within the class itself.
For simplicity, you may put your new subclasses in the same file. Separate your code from each segment with a commented line of dashes to visually denote the boundaries between questions.
You are writing a small adventure game that plays on classic fairy-tale themes: there are princes, princesses and frogs. Start with the basic class definitions in this file.
Your customers ask for new storylines that involve witches. Add a witch character (with a name like the other characters) to your class hierarchy.
Write a test case to confirm that one can create Witches with your code.
Release software (ie, add a new dashed line). Proceed to part 2.