Polymorphism and Interfaces

If we go back to thinking about interfaces, we can say that a class implements an interface if it implements all the abstract functions that make up the interface. This simply means that, if we take objects of this class, we have concrete functions we can call for each of the abstract functions in the interface. Without generic/polymorphic functions, however, we would need to know which concrete function maps to which abstract function for each class that implements a given interface. Exchanging one implementation of an interface with another would require a rewrite of the code that uses the implementation. So naturally, we would also require that the names of the concrete functions match the names of the abstract functions.

This obviously maps directly to generic functions. If, whenever we think abstract function, we map that to a generic function—one that simply calls UseMethod—and whenever we think concrete function we think implementation of a generic function—a function with a period in its name—then we have an almost automatic way of mapping the concepts of interfaces and implementations into code.

Since R doesn’t do any static type checking, there is very little you can do to guarantee that a class you write this way actually implements a given interface. There is nothing in generic functions that explicitly binds them together as an interface, so for any class you decide to implement, you can implement an arbitrary subset of generic functions. Interfaces and implementations are design concepts, and you can map the design into R code very easily, but R does not enforce that your code matches your design.

Abstract and Concrete Classes

We often unify interfaces and implementations as just classes, at least when designing software. The object-oriented way to think about software is this: every piece of data you manipulate is an object and all objects have a class that determines their behavior. By “behavior,” we just mean which functions we can call on an object. This way of thinking makes a little more sense in languages where you can modify data and where objects thus have a state. Regardless, you can think of all data as objects with associated classes that determine what you can do with them.

A class thus encapsulates both what you can do with objects—the interface you have for them—but also how it is done—how the interface is implemented.

Objects have classes, and classes determine what you can do with objects, but classes live in hierarchies of more abstract or more derived classes. A vector-based implementation of a stack is a stack. It is a special kind of stack, sure, but it is still a stack. The general concept of what a stack is is more general than vector-based implementations, so the vector implementation can be thought of as a specialisation of a stack—that is, one that is implemented using a vector.

We generally think about class hierarchies as part of “is-a” relationships. A vector implementation of a stack “is-a” stack. So is a list-based implementation. If you have an object of a more specialised class you should also be able to treat it as an object of a more abstract class. If you have a vector stack, you can treat it as a stack because its class is a vector stack class and that is a special case of the stack class.

The closest we get to interfaces and implementations is abstract classes and concrete classes. An abstract class is essentially exactly an interface. It is nothing more than a description of what you can do with objects of this class; there is no implementation associated with it. Concrete classes, on the other hand, have implementations for all the functions you can call on objects of the given class. Quite often, though, classes implement some but not all the functions their interface describes, so the distinction is not that clean in practise.

We often show classes and their relationships in diagrams as that shown in Figure 2-1. Here Stack is shown in italics to indicate that it is an abstract class. Below the class name is listed the methods you can call on the class, and errors from one class to another indicate that one class is derived from another. Here we see that vector and list stacks, here called VectorStack and ListStack are derived from Stack.

Figure 2-1. Class hierarchy for stacks

The two concrete classes only implement the methods also listed in the abstract class, and because of this, we won’t always list the methods again in the derived classes. It is to be understood that any method implemented in a more abstract class will also be implemented in more derived classes.

Implementing Abstract and Concrete Classes in R

We already saw, in the previous chapter, how the attribute class is used to determine which version of a generic function is called for a given object. This approach for dispatching generic functions is the S3 system’s way of implementing classes, but in some sense only handles concrete implementations of abstract functions. Having a generic method foo

foo <- function(object) UseMethod("foo")

that we implement for a class bar

foo.bar <- function(object) ...

only tells R how class bar implements the foo function. If foo is part of an interface that consists of several functions, it is not explicitly stated in the R code.

If we think of interfaces as a set of abstract functions, then considering these as part of a whole is something we only do informally in R. Since abstract classes are nothing more than interfaces, we can do the same for abstract classes. When we implemented the vector-based stack in the previous chapter, we did so by setting the class attribute of the objects we returned from the constructor function empty_vector_stack to vector_stack and by implementing the four functions we considered part of the stack interface: push, pop, top, and is_empty. At no point did we specify that there existed some abstract stack class and that vector_stack is a specialization of it.

Since the class mechanism implemented this way is essentially working on a per-function level—we have generic functions and implementations of these that are dispatched based on their name—classes and their relationships can be a very messy affair in R. You can alleviate this by thinking about your software design in a more structured way than the language requires. Design your software with classes in mind, implement abstract classes by defining a set of generic functions—you can use comments to group them together and to document that these constitute an interface. Make sure that when you define a concrete class implementing an interface that you don’t forget about any of the functions in the interface. You might not implement them all; sometimes there are good reasons to, and sometimes you are just being pragmatic and not implementing something that might be difficult to achieve, but that you don’t need yet. Make sure that this is a conscious choice, though, and that you haven’t simply forgotten a function.

You can use the function methods to get a list of all the methods implemented by a class

methods(class = "vector_stack")
## [1] is_empty pop      push     top
## see '?methods' for accessing help and source code

and check if you have everything implemented. You can also use this function to get a list of all classes that implement a given generic function.

methods("top")
## [1] top.default      top.list_stack
## [3] top.vector_stack
## see '?methods' for accessing help and source code

Another Example: Graphical Objects

The “is-a” relationship underlying a class hierarchy is more flexible than just having abstract classes and implementations of these. It provides us with both a way of modeling that some objects really are of different but related classes, and it provides us with a mechanism for thinking about interfaces as specializations of other interfaces.

Let us consider, for example, an application where we operate on some graphical object—perhaps as part of a new visualization package. The most basic class of this application is the GraphicalObject whose objects you can draw. Being able to draw objects is the most basic operation we need for graphical objects. Graphical objects also have a “bounding box”—a rectangle that tells us how large the shape is, something we might need when drawing objects.

This class is abstract, not just because we are defining an interface so we can have different implementations, like with did with the stack, but because it doesn’t really make sense to have a graphical interface at this abstract level. A concrete class that it does make sense to have objects of is Point, which is a graphical object representing a single point. Other classes could be Circle and Rectangle.

For dealing with more than one graphical object, in an interface which makes that easy, we also have a class, Composite, that captures a collection of graphical objects.

Figure 2-2. Class hierarchy for graphical objects. The arrow from Composite to GraphicalObject, with a diamond starting point and an arrow endpoint, indicates that a Composite consists of a collection of GraphicalObjects.

Treating a collection of objects as an object of the same class as its components is a so-called design pattern and it makes it easier to deal with complex figures in this application. We can group together graphical objects in a hierarchy—similar to how you would group objects in a drawing tool—and we would not need to explicitly check in our code if we are working on a single object or a collection of objects. A collection of objects is also a graphical object, and we can just treat it as such.

Implementing this class hierarchy is fairly straightforward. The abstract class GraphicalObject is not explicitly represented, but we need its methods as generic functions.

draw <- function(object) UseMethod("draw")
bounding_box <- function(object) UseMethod("bounding_box")

When constructing graphical objects, we need to set their class, and these could be the constructors for the concrete classes:

point <- function(x, y) {
  object <- c(x, y)
  class(object) <- "point"
  names(object) <- c("x", "y")
  object
}

rectangle <- function(x1, y1, x2, y2) {
  object <- c(x1, y1, x2, y2)
  class(object) <- "rectangle"
  names(object) <- c("x1", "y1", "x2", "y2")
  object
}

circle <- function(x, y, r) {
  object <- c(x, y, r)
  class(object) <- "circle"
  names(object) <- c("x", "y", "r")
  object
}

composite <- function(...) {
  object <- list(...)
  class(object) <- "composite"
  object
}

We just implement the graphical objects as vectors, except for the composite that we represent as a list so it can contain different types of other graphical objects. The points are just vectors of coordinates, the rectangles are represented by two coordinates, the rectangle’s lower left and upper right corners, and circles are represented by a center point and a radius.

For the draw methods, we can just use basic graphics functions:

draw.point <- function(object) {
  points(object["x"], object["y"])
}

draw.rectangle <- function(object) {
  rect(object["x1"], object["y1"], object["x2"], object["y2"])
}

draw.circle <- function(object) {
  plotrix::draw.circle(object["x"], object["y"], object["r"])
}

draw.composite <- function(object) {
  invisible(Map(draw, object))
}

We can use basic graphics functions except for the circles, where we use the draw.circle function from the plotrix package for convenience. For the collection class, we just call draw on all of the collection’s components. We wrap the call to Map in invisible because we don’t want to print a list of objects every time we call the function on the command prompt, but otherwise the implementation is straightforward.

With these functions, we can construct plots of graphical elements, see Figure 2-3.

Figure 2-3. Plot of graphical elements

plot(c(0, 10), c(0, 10),
     type = 'n', axes = FALSE, xlab = '', ylab = '')
draw(point(5,5))
draw(rectangle(2.5, 2.5, 7.5, 7.5))
draw(circle(5, 5, 4))

corners <- composite(point(2.5, 2.5), point(2.5, 7.5),
                     point(7.5, 2.5), point(7.5, 7.5))
draw(corners)

Here we have to set the size of the plot so it actually contains the elements we want to display. We have the bounding_box function for calculating what that area is, and we can implement the different methods like this:

bounding_box.point <- function(object) {
  c(object["x"], object["y"], object["x"], object["y"])
}

bounding_box.rectangle <- function(object) {
  c(object["x1"], object["y1"], object["x2"], object["y2"])
}

bounding_box.circle <- function(object) {
  c(object["x"] - object["r"], object["y"] - object["r"],
    object["x"] + object["r"], object["y"] + object["r"])
}

bounding_box.composite <- function(object) {
  if (length(object) == 0) return(c(NA, NA, NA, NA))

  bb <- bounding_box(object[[1]])
  x1 <- bb[1]
  y1 <- bb[2]
  x2 <- bb[3]
  y2 <- bb[4]

  for (element in object) {
    bb <- bounding_box(element)
    x1 <- min(x1, bb[1])
    y1 <- min(y1, bb[2])
    x2 <- max(x2, bb[3])
    y2 <- max(y2, bb[4])
  }

  c(x1, y1, x2, y2)
}

With that, we can collect all the graphical elements we wish to plot in a composite object and calculate the bounding box before we plot.

all <- composite(
  point(5,5),
  rectangle(2.5, 2.5, 7.5, 7.5),
  circle(5, 5, 4),
  composite(point(2.5, 2.5), point(2.5, 7.5),
            point(7.5, 2.5), point(7.5, 7.5))
)
bb <- bounding_box(all)
plot(c(bb[1], bb[3]), c(bb[2], bb[4]),
     type = 'n', axes = FALSE, xlab = '', ylab = '')
draw(all)

The result is, of course, just the same as seen in Figure 2-3.