Working with others’ code I: Inheritance
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.
Have a go now at making your own small class extension example.
Try and make a three class system: use our
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
it has inherited invisibly from
Point. Make sure you devise
a test to check the value.
Have a go at setting different elements to
to see how they respond.
Given the following code, all in the same directory:
The code doesn't work because ______________________________ .
countDownthe variable has the same name as a method
countDownthe variable is
privateand can't be accessed by
setCountDownis set to
- a main class can't extend another
- of all the sundry horrors, collective and diverse
- 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.
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
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.
Here's some code that replicates the banking example. Can you gets it working so you haz sum money?
The difference between an abstract class and an interface is _______________________.
- you can turn an abstract class into an object
- abstract classes could contain runnable code
- 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.
You'll need to get your head around at least the basics of UML. The best introductions are these articles by Stephen Palmer:
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:
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.
The UML shows ________________________________________.
- a Point class that implements a Land interface
- a Point class that extends a Land abstract class
- a Point class that extends a Land class
- a Land class that implements a Point interface
- a Land class that extends a Point abstract class
- 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.