Working with others’ code I: Inheritance
[Part 5]

There are three major branches to the Philosophy of Object Orientated Programming: Encapsulation, Polymorphism, and Inheritance. We've looked at Encapsulation and Polymorphism in the last part. We'll now tackle the last of these: inheritance, which is partly, you'll be delight to hear, about making our job easier, and reducing the amount of code we have to write.

Powerpoint and audio

Further info:

Have a go now at making your own small class extension example. Try and make a three class system: use our Point class from the last part, and make a Land class that extends it to add a new String instance variable owner, with the appropriate set and get methods. Finally make a main class (or adapt the one from the last part) which makes a Land class object, and sets its owner value, along with the x value it has inherited invisibly from Point. Make sure you devise a test to check the value.

Have a go at setting different elements to public, protected, and private, to see how they respond.

Quiz:

Given the following code, all in the same directory:

class MissionControl {

   private int countDown = 0;

   protected void setCountDown(int cD) {
      countDown = cD;
   }

   public void countDown() {
      while (countDown >= 0) {
         System.out.println(countDown--);
      }
      System.out.println("Blastoff");
   }
} 		public class AOk extends MissionControl {

   private AOk() {

      setCountDown(10);
      countDown();

   }

   public static void main (String args[]) {

      new AOk();

   }
}

 

The code doesn't work because ______________________________ .


  1. countDown the variable has the same name as a method
  2. countDown the variable is private and can't be accessed by AOk
  3. setCountDown is set to protected
  4. MissionControl isn't public
  5. AOk has a private constructor
  6. a main class can't extend another
  7. of all the sundry horrors, collective and diverse
  8. of the fact that... hang on, it *does* work... why I oughta...

Correct! What a minefield, but actually, all these things are ok:

1) Variables can have the same name as methods; it's variables with the same name in the same scope that cause difficulties.

2) While it is true that AOk can't access the countDown variable, it doesn't try to -- it goes through the methods.

3) setCountDown can be accessed by inheriting classes as protected; it just couldn't be accessed from anywhere else.

4) The files are all in the same directory, so the default is for them to work together -- MissionControl doesn't need to be public.

5) AOk can have a private constructor because it is only being called within itself (weird, but there you go, that's where making main static gets you...).

6) The main class is as cool as Arthur Herbert Fonzarelli; it can do what the hell it likes.


Best thing is to keep in mind the core stuff:
default : works with everything in the directory.
public : works with everything.
protected : works with code that inherits it, and itself.
private : only works with code in that object.

Further info:

Here's some code that replicates the banking example. Can you gets it working so you haz sum money?

BlueBankATM.java
BlueBankRequest.java
RedBank.java
RedBankConnection.java
GenericRequest.java

Powerpoint and audio

Quiz:

The difference between an abstract class and an interface is _______________________.

  1. you can turn an abstract class into an object
  2. abstract classes could contain runnable code
  3. abstract classes can't contain final static variables

Correct! You can't turn an abstract class into an object, as nothing would be implementing the missing methods. Abstract classes can, however, contain usable final static variables. They can also contain runnable code, which is the main difference with Interfaces.

Powerpoint and audio

Further info:

You'll need to get your head around at least the basics of UML. The best introductions are these articles by Stephen Palmer:

A Picture Can Save a Thousand Words: UML Class Diagrams and Java

More Symbols, More Diagrams, More UML: Beyond Class and Interaction Diagrams

Getting Dynamic: Java and UML Interaction Diagrams

Just Typical: UML Stereotypes and Class Archetypes

You might also like to check out...
IBM's UML tutorials

Many IDEs will produce UML (and some will read it to create basic code), however, if you want separate software, the following are good:

Dia: Basic looking, but good for a wide variety of diagrams.
Violet: Simple but good UML editor.
Argo: Complex but highly featured editor.

For the future, a good book on UML is:
UML Distilled, Martin Fowler and Kendall Scott (2003), Addison Wesley; ISBN: 0321193687 (~£24)
Although not specifically a Java book, this also contains a lot of good advice about object orientated programming.

Quiz:

The UML shows ________________________________________.

 

  1. a Point class that implements a Land interface
  2. a Point class that extends a Land abstract class
  3. a Point class that extends a Land class
  4. a Land class that implements a Point interface
  5. a Land class that extends a Point abstract class
  6. a Land class that extends a Point class

Correct! Remember that arrows point at the parent class or interface, not the subclass. Interfaces are denoted by angle-brackets and italics. Implementation of an interface is denoted by a dashed arrow.

[Key ideas from this part]
[Homepage]