Lecture 4: Methods for unions

Overview

In the last lecture we introduced simple method definitions for classes, method invocation to actually execute those methods, the notion of delegating responsibility from one object to another, and introduced how to test our methods. In this lecture, we introduce methods for union data types, and introduce the concept of dynamic dispatch.

• Designing the area method

• Dynamic dispatch

• Designing the distanceToOrigin method: Helper classes and methods

• Points: more generalization

• Designing the isBiggerThan method: more duplicated code

• Designing the contains method: more helper methods

4.1 Designing Methods for Simple Shapes

Here are our two classes that represent shapes - we defined them to implement the common interface IShape.

The class diagram below shows our ambitious program - of designing four methods for these classes.

                  +-----------------------------------+
                  | IShape                            |
                  +-----------------------------------+
                  +-----------------------------------+
                  | double area()                     |
                  | double distanceToOrigin()         |
                  | IShape grow(int inc)              |
                  | boolean isBiggerThan(IShape that) |
                  +-----------------------------------+
                                 |
                                / \
                                ---
                                 |
               -------------------------------
               |                             |
+-----------------------------------+        |
| Circle                            |        |
+-----------------------------------+        |
| int x                             |        |
| int y                             |        |
| int radius                        |        |
| String color                      |        |
+-----------------------------------+        |
| double area()                     |        |
| double distanceToOrigin()         |        |
| IShape grow(int inc)              |        |
| boolean isBiggerThan(IShape that) |        |
+-----------------------------------+        |
                                             |
                      +-----------------------------------+
                      | Square                            |
                      +-----------------------------------+
                      | int x                             |
                      | int y                             |
                      | int size                          |
                      | String color                      |
                      +-----------------------------------+
                      | double area()                     |
                      | double distanceToOrigin()         |
                      | IShape grow(int inc)              |
                      | boolean isBiggerThan(IShape that) |
                      +-----------------------------------+

We want to design the following methods that would work for any shape - the two we have defined now, and any other shape class we may define in the future (for example a Triangle class).

4.2 Designing the area method: dynamic dispatch

To compute the area of a shape in DrRacket, the function purpose, signature and header would have been:

;; to compute the area of the given shape

;; area : Shape -> Number

(define (area ashape) ...)

and the template would have been:

;; to compute the area of the given shape

;; area : Shape -> Number

(define (area ashape)

(cond

[(circle? ashape) ...]

[(square? ashape) ...]))

In Java the methods that deal with each type of object are defined within the corresponding class definitions for those objects. So the area method that computes the area of a circle is defined in the Circle class, and the area method that computes the area of a square is defined in the Square class.

A union of several classes in Java is represented by an interface type. We would like to assure that every class that implements our IShape interface does indeed define the method area. The interface definition, that so far was just an empty shell of code, is now used to define method headers for some methods. Interfaces define a signature: one that must be upheld by every class that claims to implement the interface, and that can be relied upon by every client of the interface. Specifically, every class that implements the interface is required to implement all methods that the interface specifies. In turn, whenever we use any object of the type specified by the interface, we are guaranteed that we can invoke every method defined in the interface on this object.

Do Now!

Define the remaining methods for the classes Circle and Square:

// In IShape // to compute the distance from this shape to the origin double distanceToOrigin();

// to increase the size of this shape by the given increment IShape grow(int inc);

// is the area of this shape bigger than // the area of the given shape? boolean isBiggerThan(IShape that);

One of these might require more helper methods than have been defined so far.

4.3 Dynamic dispatch

Something should have seemed a bit odd in the examples above. How did Java “know” that when we wrote this.c1.area(), we intended to invoke the area method defined in the Circle class, and that when we wrote this.s1.area(), we intended to invoke the method defined in the Square class? After all, both s1 and c1 are declared as having type IShape — and interfaces don’t define any method implementations at all!

Can you tell, just from looking at that snippet of code, what kind of shape this method is given? No! Said another way, all we know statically — that is, by looking at the text of our program — is that the argument aShape is some IShape. However, dynamically — that is, when we run the program and this method gets invoked — we must have some specific shape at hand. And it is only at that moment in the program’s execution that we could determine which area method to invoke.

This process, of dispatching to the correct method implementation based on information available only dynamically, is called dynamic dispatch, and it is one of the cornerstone concepts of object-oriented programming.

Do Now!

Look back at the Racket template for the area function, and compare it to the implementation of the area methods in Circle and Square. Do you see anything missing in the Java version?

Notice that the Java version of this method has no explicit cond expression, or any expressions like circle? or square? at all. What was the purpose of that cond? It distinguished between the different variants of our union data type. In an object-oriented language, this is precisely the purpose of dynamic dispatch: the language itself distinguishes between the variants, and dispatches to the correct method implementation for you, without you having to write any explicit variant-testing code.

If you find yourself wanting to write an expression like square? or circle?, stop! Re-read this portion of the lecture notes, and then redesign your code to use a method on an interface and dynamic dispatch instead.

4.4 Designing the distanceToOrigin method

Notice that these two methods are very similar, are operating on nearly identical data, and are producing nearly the same result. If only we didn’t have to write out the Pythagorean formula twice – chances are good we’ll make a mistake at least once. And what if in the future we add more kinds of IShapes: will we have to write the formula again?

Also confusing: while both shapes have x and y fields, they mean slightly different things: the center of the circle versus the top-left corner of the square.

At this point, the design recipe for abstraction says “make a helper function”. But Java has no functions: it only has classes, interfaces, and methods. But that gives us an idea. We can solve all these problems at once, by factoring out the x and y fields into a helper class, which we will call CartPt (for Cartesian Point).

Do Now!

Revise the class diagram above to include CartPt and these changes to Circle and Square.

Do Now!

Revise the distanceToOrigin methods in Circle and Square to delegate to this method on CartPt.

Much better! This is one common example of an important principle in program design: Don’t Repeat Yourself. If there is a way to refactor your code, to extract common elements and separate them into reusable abstractions, it’s probably a good idea to do that.

In this case, we get to extend our template with a new section, methods of fields, that gives us access to exactly the new functionality that we need.

Do Now!

Design a method boolean contains(CartPt point) for IShapes that returns true if the given point is within the shape.

4.5 What’s so special about Cartesian coordinates, anyway?

There is a subtle, but very powerful, benefit to abstracting x and y into their own class. Notice now that there is no code, outside the CartPt class itself, that knows or cares about x or y fields. So if we wanted to, we could represent our points as PolarPt, with r and theta fields instead.

4.6 Designing the isBiggerThan method

The implementations of both methods are identical! We’ll see in Lecture 9: Abstract classes and inheritance how to eliminate this duplication.

4.7 Designing the contains method

Note: this section assumes that you are working with CartPt directly, rather than the generalization to IPoint. (See What’s so special about Cartesian coordinates, anyway?)

4.8 Putting it all together: Lots of Examples

We define several examples of each class we’ve built so far, and test all the methods on them. Notice two things about these examples: first, we declare the types of all our shapes to be IShape, rather than Circle or Square, because we were designing a union type. Second, notice that despite declaring the examples to all have type IShape, Java still correctly calls the methods defined in the Circle class for examples c1, c2 and c3, and the methods defined in the Square class for examples s1, s2 and s3. This is dynamic dispatch in action.

Exercise

Define a new shape, Combo, that contains two IShapes. Its distanceToOrigin should be the minimum of the distances of its two components, its area should be the sum of the areas of its two components, it can grow by growing both of its components, and it contains a CartPt if either of its components contains the given point.