RedKangaroo, a Subclass of Kangaroo
In this activity you will create a new class called RedKangaroo, as a subclass of Kangaroo. When you create a subclass, fields and methods are inherited from the parent class (the parent class is also known as the superclass). This means that if you don't write any new code, the subclass will use all of the code from the superclass without you doing anything. It's actually not quite that straightforward as there are ways that the superclass can hide things from subclasses, but in general, that's what the subclassing mechanism is for – inheriting code from the superclass.
Subclassing is sometimes called specializing, and a subclass may be referred to as a specialization of the superclass. When you subclass, you can add new methods (new behaviors), and you can also override existing methods by writing a method with the same name in your subclass. This is where the term specialization comes from; your subclass may behave in different, special ways from the superclass. Similarly, a superclass is sometimes referred to as a generalization. General behavior belongs in the superclass, special (specific) behavior belongs in a subclass.
A quick example – if you were working on code that modeled dogs, you might have a superclass called Canine, and subclasses called DomesticDog and WildDog. Canine would have common characteristics of dogs: size, weight, age, type of fur (coarse, smooth, curly). DomesticDog would have fields and methods that are only applicable to domestic dogs, such as owner, whether it sleeps in the house or outside, does it wear a coat in cold weather, etc. WildDog would have fields and methods that are only applicable to dogs that are not intended as pets. DomesticDog and WildDog are specializations of Canine; Canine is a generalization of DomesticDog and WildDog.
Making the RedKangaroo Turn
Let's give our RedKangaroo class a method called turnRight(). This is an example of specialized behavior; all Kangaroos can turn left, but only RedKangaroos can also turn right. Double-click on RedKangaroo to open the source code for the RedKangaroo class in the Greenfoot class editor, and copy and paste the code from below into the class, after the act() method, and just before the very last } character, which marks the end of the class definition (note that {} always come in pairs) :
/** |
Again we see the method name turnRight followed by empty “( )” meaning that it has no parameters (arguments). It is public, which means that it is visible by all classes or code in its containing package. The word void just before the method name means that it returns no value. Some methods give a return value on completion. We’ll show some examples of methods that return values later.
Now add the following code to RedKangaroo.act():
if(foundLeaf()) { |
This is the same code as Wombat.act(), except that now we're calling turnRight() instead of turnLeft().
Inside turnRight is something called a switch statement. direction is the ‘key’ in the switch. Each case statement is evaluated and when a match to direction is found, the code below it is executed. For example, if direction is ‘EAST’, the statement:
case EAST: |
is run. setDirection(SOUTH) sets direction to SOUTH! No surprise there! ;-) But what is break for? break jumps us down to the end of the switch statement to make sure it does not keep going and run the code for case(NORTH) and case(WEST). But wait? Where is direction? That’s right. We have to go back to class Kangaroo to find it:
public class Kangaroo extends Actor |
Currently, the code for Kangaroo has:
private int direction; |
At this point, compile your RedKangaroo. You will notice that there is an error message in the message field at the bottom of the editor window, “direction has private access in Kangaroo.” Double click on Kangaroo, and change the private modifier to say protected; Kangaroo should now have:
protected int direction; |
Object Oriented languages support another feature, called encapsulation. Encapsulation allows you to hide some parts of your code from other parts of the program. Using encapsulation can help prevent errors in your program, and is generally considered good practice. For now, don't worry about the details of why encapsulation is good; just understand that there is such a thing, and that it's a defining characteristic of an object oriented programming (along with inheritance and some other nifty features). The private, protected, and public modifiers are used to define access rules for your data, and can be used to encapsulate the data. In this case, the integer variable called direction was specified as private; this means that the data is only visible to the Kangaroo class, and when we tried to use it in the RedKangaroo class, we could not, even though RedKangaroo is a subclass of Kangaroo! In order to give subclasses access to the direction variable, we changed the access modifier to protected, which says that all subclasses can also access the variable. The other modifier, public, says that any code can access the data. Fortunately, the compiler caught the error and told us that direction could not be found, and forced us to fix it before it created our runnable program.
Try to compile again, and you'll see that we have the same issue for EAST, WEST, NORTH and SOUTH. Change them all to protected to give RedKangaroo access to these fields and will be able to compile with no errors.

