4
$\begingroup$

After teaching inheritance and implementation (implements vs extends in Java) and overriding methods and basic OOP (classes and interfaces), as well as polymorphism (up/downcasting) I want to give the students some exercises to practice this.

Currently, I have the famous Animal -> Mammal example, as well as Human -> Teacher, Human -> Student.

I am trying to think of new examples and exercises to practice the subjects mentioned. To give a better notion of what I'm looking for, the Animal exercise looks like this:

public abstract class Animal implements AnimalActions {
    private String name, family;
    private double weight;

    public Animal(String name, String family, double weight) {
        this.name = name;
        this.family = family;
        this.weight = weight;
    }
}

interface AnimalActions {
    public void eat();

    public void sleep();

    public void makeSound();
}

And then:

public class Mammal extends Animal {
    public Mammal(String name, String family, double weight) {
        super(name, family, weight);
    }

    @Override
    public void eat() {

    }

    @Override
    public void sleep() {

    }

    @Override
    public void makeSound() {

    }
}

This covers many things and is useful for teaching. However, this doesn't go very far if I make it into a practice exercise. What exercises do others give students in this subject?

The students are in high school.

$\endgroup$
  • 1
    $\begingroup$ Have you covered polymorphism with them at this point? (ArrayList<Animal> a = new ArrayList<Animal>(); a.add(new Mammal());)? $\endgroup$ – Ben I. Jun 3 '17 at 15:44
  • $\begingroup$ @BenI. Yes. I forgot to write that. I'll edit to include it $\endgroup$ – ItamarG3 Jun 3 '17 at 15:46
  • 1
    $\begingroup$ Consider changing title to be more in line with other titles. $\endgroup$ – Ellen Spertus Jun 3 '17 at 16:38
  • 1
    $\begingroup$ My classes do a lot with GUI/Event-Driven programming because this is a very natural realm in which to use inheritance. $\endgroup$ – ncmathsadist Jun 5 '17 at 13:38
  • $\begingroup$ If you don't mind, I'm going to link the answer I just supplied on another question. $\endgroup$ – Draco18s Jun 22 '17 at 17:56
2
$\begingroup$

One example that isn't necessarily exciting but would allow for a lot of class design is a Shape interface. From there let's say you have Quadrilateral, Ellipse, and Triangle as classes which implement Shape. You could do some really cool things by including as methods formulas for area and perimeter.

Additionally, within Quadrilateral, you could further subclass into Parallelogram (and further with Rhombus and Rectangle and Square?), Trapezoid, and Kite. Students will clearly see the relationship of Shape -> Quadrilateral -> Parallelogram -> Rectangle -> Square. This will also hammer home the ideas that a subclass IS-A class as in a square IS-A rectangle and that the inverse (a class IS-A subclass) is not true.

This can lead to fun, but important design conversations. Do you indeed make a subclass for Square, or do you have an isSquare() method on Rectangle testing for equality of length and width?

A second example is this: give the students this challenge. Just as we are coming up with examples of how to categorize objects with IS-A relationships, so too should students come up with their own system of inheritance. I would bet that they would come up with some pretty inventive ideas. Moreover, the power of class design in OOP will "stick" if they come up with the system from the ground up.

$\endgroup$
  • $\begingroup$ I very much like the idea of asking them to be creative. Thanks! $\endgroup$ – ItamarG3 Jun 4 '17 at 6:24
  • 1
    $\begingroup$ I like to use the example of Square inheriting from Rectangle vs inheriting from Shape. What happens to a Square (with a given Side length) if you set Width different from Height? After working it out, it shows that inheritance should have one responsibility - to fit the base interface Shape. It doesn't always make sense for types to derive from each other. Think Liskov Substitution Principle. $\endgroup$ – John Deters Jun 22 '17 at 0:39
3
$\begingroup$

You could have a hierarchy based on an abstract class or interface Car, with implementations/subclasses for ElectricCar, HybridCar, GasBurningCar, etc. This illustrates that there can be very different implementations for an interface.

Each class would have different additional members. For example, a GasBurningCar could have a maximum amount of gas (in gallons or liters), represented as an int or double, or it could have a field of type GasTank. Having members gives students practice with has-a relationships, in addition to is-a relationships.

You could discuss trade-offs in whether an individual car model, such as Prius, should be an instance of HybridCar or a subclass.

$\endgroup$
  • $\begingroup$ This is an interesting Idea to show them the is-a and has-a relationships. For some reason, students sometimes get confused with those $\endgroup$ – ItamarG3 Jun 3 '17 at 16:42
2
$\begingroup$

I have used an example of a machine which has a serial number and a state. It can be turned on and off, it can be told to give out its serial number. A bMachine can be powercycled (inheritance from machine). There is a machinedesk which contains machines. They can self check.

I worked through a whole range of 'things' that the objects could do to demonstrate everything in the AQA A-level spec in Python. I then got students to take what I had demonstrated and build joke machines.

The purpose of this is the context - students struggle to see why on earth you would model an animal whilst they can see a simple extension to allow these objects to control actual machines.

$\endgroup$
1
$\begingroup$

You could have different implementations of a bit of hardware, e.g. printer.

Or a concept such as sorting. sort ⇐ bubble sort, sort ⇐ merge sort, sort ⇐ insertion sort, sort ⇐ quick sort, sort ⇐ a hybrid sort, …

A stack implemented with an array and with a linked list.

A queue implemented with an array (circular buffer) and with a linked list.


Objects are not always objects. We need to remember and teach, that not all Objects (in Object orientation), are objects. Some are algorithms (The sort algorithm, so still a noun ).

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.