Файл: Programming_in_Scala,_2nd_edition.pdf

Chapter 10

Composition and Inheritance

Chapter 6 introduced some basic object-oriented aspects of Scala. This chapter will pick up where Chapter 6 left off and dive with much greater detail into Scala’s support for object-oriented programming. We’ll compare two fundamental relationships between classes: composition and inheritance. Composition means one class holds a reference to another, using the referenced class to help it fulfill its mission. Inheritance is the superclass/subclass relationship. In addition to these topics, we’ll discuss abstract classes, parameterless methods, extending classes, overriding methods and fields, parametric fields, invoking superclass constructors, polymorphism and dynamic binding, final members and classes, and factory objects and methods.

10.1 A two-dimensional layout library

As a running example in this chapter, we’ll create a library for building and rendering two-dimensional layout elements. Each element will represent a rectangle filled with text. For convenience, the library will provide factory methods named “elem” that construct new elements from passed data. For example, you’ll be able to create a layout element containing a string using a factory method with the following signature:

elem(s: String): Element

As you can see, elements will be modeled with a type named Element. You’ll be able to call above or beside on an element, passing in a second element, to get a new element that combines the two. For example,

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

the following expression would construct a larger element consisting of two columns, each with a height of two:

val column1 = elem("hello") above elem("***") val column2 = elem("***") above elem("world") column1 beside column2

Printing the result of this expression would give:

hello ***

*** world

Layout elements are a good example of a system in which objects can be constructed from simple parts with the aid of composing operators. In this chapter, we’ll define classes that enable element objects to be constructed from arrays, lines, and rectangles—the simple parts. We’ll also define composing operators above and beside. Such composing operators are also often called combinators because they combine elements of some domain into new elements.

Thinking in terms of combinators is generally a good way to approach library design: it pays to think about the fundamental ways to construct objects in an application domain. What are the simple objects? In what ways can more interesting objects be constructed out of simpler ones? How do combinators hang together? What are the most general combinations? Do they satisfy any interesting laws? If you have good answers to these questions, your library design is on track.

10.2 Abstract classes

Our first task is to define type Element, which represents layout elements. Since elements are two dimensional rectangles of characters, it makes sense to include a member, contents, that refers to the contents of a layout element. The contents can be represented as an array of strings, where each string represents a line. Hence, the type of the result returned by contents will be Array[String]. Listing 10.1 shows what it will look like.

In this class, contents is declared as a method that has no implementation. In other words, the method is an abstract member of class Element. A class with abstract members must itself be declared abstract, which is done by writing an abstract modifier in front of the class keyword:

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

abstract class Element {

def contents: Array[String]

}

Listing 10.1 · Defining an abstract method and class.

abstract class Element ...

The abstract modifier signifies that the class may have abstract members that do not have an implementation. As a result, you cannot instantiate an abstract class. If you try to do so, you’ll get a compiler error:

scala> new Element

<console>:5: error: class Element is abstract; cannot be instantiated

new Element

ˆ

Later in this chapter you’ll see how to create subclasses of class Element, which you’ll be able to instantiate because they fill in the missing definition for contents.

Note that the contents method in class Element does not carry an abstract modifier. A method is abstract if it does not have an implementation (i.e., no equals sign or body). Unlike Java, no abstract modifier is necessary (or allowed) on method declarations. Methods that do have an implementation are called concrete.

Another bit of terminology distinguishes between declarations and definitions. Class Element declares the abstract method contents, but currently defines no concrete methods. In the next section, however, we’ll enhance Element by defining some concrete methods.

10.3 Defining parameterless methods

As a next step, we’ll add methods to Element that reveal its width and height, as shown in Listing 10.2. The height method returns the number of lines in contents. The width method returns the length of the first line, or, if there are no lines in the element, zero. (This means you cannot define an element with a height of zero and a non-zero width.)

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

abstract class Element {

def contents: Array[String]

def height: Int = contents.length

def width: Int = if (height == 0) 0 else contents(0).length

}

Listing 10.2 · Defining parameterless methods width and height.

Note that none of Element’s three methods has a parameter list, not even an empty one. For example, instead of:

def width(): Int

the method is defined without parentheses:

def width: Int

Such parameterless methods are quite common in Scala. By contrast, methods defined with empty parentheses, such as def height(): Int, are called empty-paren methods. The recommended convention is to use a parameterless method whenever there are no parameters and the method accesses mutable state only by reading fields of the containing object (in particular, it does not change mutable state). This convention supports the uniform access principle,1 which says that client code should not be affected by a decision to implement an attribute as a field or method. For instance, we could have chosen to implement width and height as fields instead of methods, simply by changing the def in each definition to a val:

abstract class Element {

def contents: Array[String] val height = contents.length val width =

if (height == 0) 0 else contents(0).length

}

The two pairs of definitions are completely equivalent from a client’s point of view. The only difference is that field accesses might be slightly faster than method invocations, because the field values are pre-computed when the

1Meyer, Object-Oriented Software Construction [Mey00]

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

class is initialized, instead of being computed on each method call. On the other hand, the fields require extra memory space in each Element object. So it depends on the usage profile of a class whether an attribute is better represented as a field or method, and that usage profile might change over time. The point is that clients of the Element class should not be affected when its internal implementation changes.

In particular, a client of class Element should not need to be rewritten if a field of that class gets changed into an access function so long as the access function is pure, i.e., it does not have any side effects and does not depend on mutable state. The client should not need to care either way.

So far so good. But there’s still a slight complication that has to do with the way Java handles things. The problem is that Java does not implement the uniform access principle. So it’s string.length() in Java, not string.length (even though it’s array.length, not array.length()). Needless to say, this is very confusing.

To bridge that gap, Scala is very liberal when it comes to mixing parameterless and empty-paren methods. In particular, you can override a parameterless method with an empty-paren method, and vice versa. You can also leave off the empty parentheses on an invocation of any function that takes no arguments. For instance, the following two lines are both legal in Scala:

Array(1, 2, 3).toString "abc".length

In principle it’s possible to leave out all empty parentheses in Scala function calls. However, it is recommended to still write the empty parentheses when the invoked method represents more than a property of its receiver object. For instance, empty parentheses are appropriate if the method performs I/O, or writes reassignable variables (vars), or reads vars other than the receiver’s fields, either directly or indirectly by using mutable objects. That way, the parameter list acts as a visual clue that some interesting computation is triggered by the call. For instance:

To summarize, it is encouraged style in Scala to define methods that take no parameters and have no side effects as parameterless methods, i.e., leaving off the empty parentheses. On the other hand, you should never define a

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

method that has side-effects without parentheses, because then invocations of that method would look like a field selection. So your clients might be surprised to see the side effects. Similarly, whenever you invoke a function that has side effects, be sure to include the empty parentheses when you write the invocation. Another way to think about this is if the function you’re calling performs an operation, use the parentheses, but if it merely provides access to a property, leave the parentheses off.

10.4 Extending classes

We still need to be able to create new element objects. You have already seen that “new Element” cannot be used for this because class Element is abstract. To instantiate an element, therefore, we will need to create a subclass that extends Element and implements the abstract contents method. Listing 10.3 shows one possible way to do that:

class ArrayElement(conts: Array[String]) extends Element { def contents: Array[String] = conts

}

Listing 10.3 · Defining ArrayElement as a subclass of Element.

Class ArrayElement is defined to extend class Element. Just like in Java, you use an extends clause after the class name to express this:

... extends Element ...

Such an extends clause has two effects: it makes class ArrayElement inherit all non-private members from class Element, and it makes the type

ArrayElement a subtype of the type Element. Given ArrayElement extends Element, class ArrayElement is called a subclass of class Element. Conversely, Element is a superclass of ArrayElement.

If you leave out an extends clause, the Scala compiler implicitly assumes your class extends from scala.AnyRef, which on the Java platform is the same as class java.lang.Object. Thus, class Element implicitly extends class AnyRef. You can see these inheritance relationships in Figure 10.1.

Inheritance means that all members of the superclass are also members of the subclass, with two exceptions. First, private members of the super-

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

scala

AnyRef

«java.lang.Object»

Element

«abstract»

ArrayElement Array[String]

Figure 10.1 · Class diagram for ArrayElement.

class are not inherited in a subclass. Second, a member of a superclass is not inherited if a member with the same name and parameters is already implemented in the subclass. In that case we say the member of the subclass overrides the member of the superclass. If the member in the subclass is concrete and the member of the superclass is abstract, we also say that the concrete member implements the abstract one.

For example, the contents method in ArrayElement overrides (or, alternatively: implements) abstract method contents in class Element.2 By contrast, class ArrayElement inherits the width and height methods from class Element. For example, given an ArrayElement ae, you can query its width using ae.width, as if width were defined in class ArrayElement:

scala> val ae = new ArrayElement(Array("hello", "world")) ae: ArrayElement = ArrayElement@d94e60

scala> ae.width res1: Int = 5

2One flaw with this design is that because the returned array is mutable, clients could change it. For the book we’ll keep things simple, but were ArrayElement part of a real project, you might consider returning a defensive copy of the array instead. Another problem is we aren’t currently ensuring that every String element of the contents array has the same length. This could be solved by checking the precondition in the primary constructor, and throwing an exception if it is violated.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

Subtyping means that a value of the subclass can be used wherever a value of the superclass is required. For example:

val e: Element = new ArrayElement(Array("hello"))

Variable e is defined to be of type Element, so its initializing value should also be an Element. In fact, the initializing value’s type is ArrayElement. This is OK, because class ArrayElement extends class Element, and as a result, the type ArrayElement is compatible with the type Element.3

Figure 10.1 also shows the composition relationship that exists between ArrayElement and Array[String]. This relationship is called composition because class ArrayElement is “composed” out of class Array[String], in that the Scala compiler will place into the binary class it generates for ArrayElement a field that holds a reference to the passed conts array. We’ll discuss some design considerations concerning composition and inheritance later in this chapter, in Section 10.11.

10.5 Overriding methods and fields

The uniform access principle is just one aspect where Scala treats fields and methods more uniformly than Java. Another difference is that in Scala, fields and methods belong to the same namespace. This makes it possible for a field to override a parameterless method. For instance, you could change the implementation of contents in class ArrayElement from a method to a field without having to modify the abstract method definition of contents in class Element, as shown in Listing 10.4:

class ArrayElement(conts: Array[String]) extends Element { val contents: Array[String] = conts

}

Listing 10.4 · Overriding a parameterless method with a field.

Field contents (defined with a val) in this version of ArrayElement is a perfectly good implementation of the parameterless method contents (declared with a def) in class Element.

3For more perspective on the difference between subclass and subtype, see the glossary entry for subtype.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index

On the other hand, in Scala it is forbidden to define a field and method with the same name in the same class, whereas it is allowed in Java. For example, this Java class would compile just fine:

// This is Java class CompilesFine {

private int f = 0; public int f() {

return 1;

}

}

But the corresponding Scala class would not compile:

class WontCompile {

private var f = 0 // Won’t compile, because a field def f = 1 // and method have the same name

}

Generally, Scala has just two namespaces for definitions in place of Java’s four. Java’s four namespaces are fields, methods, types, and packages. By contrast, Scala’s two namespaces are:

•values (fields, methods, packages, and singleton objects)

•types (class and trait names)

The reason Scala places fields and methods into the same namespace is precisely so you can override a parameterless method with a val, something you can’t do with Java.4

10.6 Defining parametric fields

Consider again the definition of class ArrayElement shown in the previous section. It has a parameter conts whose sole purpose is to be copied into the contents field. The name conts of the parameter was chosen just so that

4The reason that packages share the same namespace as fields and methods in Scala is to enable you to import packages in addition to just importing the names of types, and the fields and methods of singleton objects. This is also something you can’t do in Java. It will be described in Section 13.3.

Cover · Overview · Contents · Discuss · Suggest · Glossary · Index