Odersky M. Programming in Scala
Подождите немного. Документ загружается.
Section 27.4 Chapter 27 · Modular Programming Using Objects 561
object SimpleBrowser extends Browser {
val database = SimpleDatabase
}
Listing 27.9 · The SimpleBrowser object as a Browser subclass.
scala> SimpleBrowser.recipesUsing(apple)
res1: List[Recipe] = List(fruit salad)
Now, however, you can create a second mock database, and use the same
browser class with it, as shown in Listing 27.10:
object StudentDatabase extends Database {
object FrozenFood extends Food("FrozenFood")
object HeatItUp extends Recipe(
"heat it up",
List(FrozenFood),
"Microwave the 'food' for 10 minutes.")
def allFoods = List(FrozenFood)
def allRecipes = List(HeatItUp)
def allCategories = List(
FoodCategory("edible", List(FrozenFood)))
}
object StudentBrowser extends Browser {
val database = StudentDatabase
}
Listing 27.10 · A student database and browser.
27.4 Splitting modules into traits
Often a module is too large to fit comfortably into a single file. When that
happens, you can use traits to split a module into separate files. For example,
suppose you wanted to move categorization code out of the main Database
file and into its own. You could create a trait for the code as shown in List-
ing 27.11.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.4 Chapter 27 · Modular Programming Using Objects 562
trait FoodCategories {
case class FoodCategory(name: String, foods: List[Food])
def allCategories: List[FoodCategory]
}
Listing 27.11 · A trait for food categories.
Now class Database can mix in the FoodCategories trait instead of defin-
ing FoodCategory and allCategories itself, as shown in Listing 27.12:
abstract class Database extends FoodCategories {
def allFoods: List[Food]
def allRecipes: List[Recipe]
def foodNamed(name: String) =
allFoods.find(f => f.name == name)
}
Listing 27.12 · A Database class that mixes in the FoodCategories trait.
Continuing in this way, you might try and divide SimpleDatabase into
two traits, one for foods and one for recipes. This would allow you to define
SimpleDatabase, for example, as shown in Listing 27.13:
object SimpleDatabase extends Database
with SimpleFoods with SimpleRecipes
Listing 27.13 · A SimpleDatabase object composed solely of mixins.
The SimpleFoods trait could look as shown in Listing 27.14:
trait SimpleFoods {
object Pear extends Food("Pear")
def allFoods = List(Apple, Pear)
def allCategories = Nil
}
Listing 27.14 · A SimpleFoods trait.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.4 Chapter 27 · Modular Programming Using Objects 563
So far so good, but unfortunately, a problem arises if you try to define a
SimpleRecipes trait like this:
trait SimpleRecipes { // Does not compile
object FruitSalad extends Recipe(
"fruit salad",
List(Apple, Pear), // Uh oh
"Mix it all together."
)
def allRecipes = List(FruitSalad)
}
The problem here is that Pear is located in a different trait from the one that
uses it, so it is out of scope. The compiler has no idea that SimpleRecipes
is only ever mixed together with SimpleFoods.
There is a way you can tell this to the compiler, however. Scala provides
the self type for precisely this situation. Technically, a self type is an assumed
type for this whenever this is mentioned within the class. Pragmatically,
a self type specifies the requirements on any concrete class the trait is mixed
into. If you have a trait that is only ever used when mixed in with another
trait or traits, then you can specify that those other traits should be assumed.
In the present case, it is enough to specify a self type of SimpleFoods, as
shown in Listing 27.15:
trait SimpleRecipes {
this: SimpleFoods =>
object FruitSalad extends Recipe(
"fruit salad",
List(Apple, Pear), // Now Pear is in scope
"Mix it all together."
)
def allRecipes = List(FruitSalad)
}
Listing 27.15 · A SimpleRecipes trait with a self type.
Given the new self type, Pear is now available. Implicitly, the reference
to Pear is thought of as this.Pear. This is safe, because any concrete
class that mixes in SimpleRecipes must also be a subtype of SimpleFoods,
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.5 Chapter 27 · Modular Programming Using Objects 564
which means that Pear will be a member. Abstract subclasses and traits do
not have to follow this restriction, but since they cannot be instantiated with
new, there is no risk that the this.Pear reference will fail.
27.5 Runtime linking
One final feature of Scala modules is worth emphasizing: they can be linked
together at runtime, and you can decide which modules will link to which
depending on runtime computations. For example, Listing 27.16 shows a
small program that chooses a database at runtime and then prints out all the
apple recipes in it:
object GotApples {
def main(args: Array[String]) {
val db: Database =
if(args(0) == "student")
StudentDatabase
else
SimpleDatabase
object browser extends Browser {
val database = db
}
val apple = SimpleDatabase.foodNamed("Apple").get
for(recipe <- browser.recipesUsing(apple))
println(recipe)
}
}
Listing 27.16 · An app that dynamically selects a module implementation.
Now, if you use the simple database, you will find a recipe for fruit salad. If
you use the student database, you will find no recipes at all using apples:
$ scala GotApples simple
fruit salad
$ scala GotApples student
$
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.6 Chapter 27 · Modular Programming Using Objects 565
Configuring with Scala code
You may wonder if you are not backsliding to the hard links problem
of the original examples in this chapter, because the GotApples object
shown in Listing 27.16 contains hard links to both StudentDatabase
and SimpleDatabase. The difference here is that the hard links are
localized in one file that can be replaced.
Every modular application needs some way to specify the actual module
implementations to use in a particular situation. This act of “configur-
ing” the application will by definition involve the naming of concrete
module implementations. For example, in a Spring application, you
configure by naming implementations in an external XML file. In Scala,
you can configure via Scala code itself. One advantage to using Scala
source over XML for configuration is that the process of running your
configuration file through the Scala compiler should uncover any mis-
spellings in it prior to its actual use.
27.6 Tracking module instances
Despite using the same code, the different browser and database modules cre-
ated in the previous section really are separate modules. This means that each
module has its own contents, including any nested classes. FoodCategory
in SimpleDatabase, for example, is a different class from FoodCategory
in StudentDatabase!
scala> val category = StudentDatabase.allCategories.head
category: StudentDatabase.FoodCategory =
FoodCategory(edible,List(FrozenFood))
scala> SimpleBrowser.displayCategory(category)
<console>:12: error: type mismatch;
found : StudentDatabase.FoodCategory
required: SimpleBrowser.database.FoodCategory
SimpleBrowser.displayCategory(category)
ˆ
If instead you prefer all FoodCategorys to be the same, you can accomplish
this by moving the definition of FoodCategory outside of any class or trait.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.6 Chapter 27 · Modular Programming Using Objects 566
The choice is yours, but as it is written, each Database gets its own, unique
FoodCategory class.
The two FoodCategory classes shown in the previous example really
are different, so the compiler is correct to complain. Sometimes, though,
you may encounter a case where two types are the same but the compiler
can’t verify it. You will see the compiler complaining that two types are not
the same, even though you as the programmer know they perfectly well are.
In such cases you can often fix the problem using singleton types. For
example, in the GotApples program, the type checker does not know that db
and browser.database are the same. This will cause type errors if you try
to pass categories between the two objects:
object GotApples {
// same definitions...
for (category <- db.allCategories)
browser.displayCategory(category)
// ...
}
GotApples2.scala:14: error: type mismatch;
found : db.FoodCategory
required: browser.database.FoodCategory
browser.displayCategory(category)
ˆ
one error found
To avoid this error, you need to inform the type checker that they are the same
object. You can do this by changing the definition of browser.database as
shown in Listing 27.17:
object browser extends Browser {
val database: db.type = db
}
Listing 27.17 · Using a singleton type.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 27.7 Chapter 27 · Modular Programming Using Objects 567
This definition is the same as before except that database has the funny-
looking type db.type. The “.type” on the end means that this is a singleton
type. A singleton type is extremely specific and holds only one object, in
this case, whichever object is referred to by db. Usually such types are too
specific to be useful, which is why the compiler is reluctant to insert them
automatically. In this case, though, the singleton type allows the compiler to
know that db and browser.database are the same object, enough informa-
tion to eliminate the type error.
27.7 Conclusion
This chapter has shown how to use Scala’s objects as modules. In addition
to simple static modules, this approach gives you a variety of ways to create
abstract, reconfigurable modules. There are actually even more abstraction
techniques than shown, because anything that works on a class, also works
on a class used to implement a module. As always, how much of this power
you use should be a matter of taste.
Modules are part of programming in the large, and thus are hard to ex-
periment with. You need a large program before it really makes a difference.
Nonetheless, after reading this chapter you know which Scala features to
think about when you want to program in a modular style. Think about these
techniques when you write your own large programs, and recognize these
coding patterns when you see them in other people’s code.
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Chapter 28
Object Equality
Comparing two values for equality is ubiquitous in programming. It is also
more tricky than it looks at first glance. This chapter looks at object equality
in detail and gives some recommendations to consider when you design your
own equality tests.
28.1 Equality in Scala
As mentioned in Section 11.2, the definition of equality is different in Scala
and Java. Java has two equality comparisons: the == operator, which is the
natural equality for value types and object identity for reference types, and
the equals method, which is (user-defined) canonical equality for reference
types. This convention is problematic, because the more natural symbol, ==,
does not always correspond to the natural notion of equality. When program-
ming in Java, a common pitfall for beginners is to compare objects with ==
when they should have been compared with equals. For instance, compar-
ing two strings x and y using “x == y” might well yield false in Java, even
if x and y have exactly the same characters in the same order.
Scala also has an equality method signifying object identity, but it is
not used much. That kind of equality, written “x eq y”, is true if x and
y reference the same object. The == equality is reserved in Scala for the
“natural” equality of each type. For value types, == is value comparison, just
like in Java. For reference types, == is the same as equals in Scala. You can
redefine the behavior of == for new types by overriding the equals method,
which is always inherited from class Any. The inherited equals, which takes
effect unless overridden, is object identity, as is the case in Java. So equals
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 28.2 Chapter 28 · Object Equality 569
(and with it, ==) is by default the same as eq, but you can change its behavior
by overriding the equals method in the classes you define. It is not possible
to override == directly, as it is defined as a final method in class Any. That is,
Scala treats == as if it were defined as follows in class Any:
final def == (that: Any): Boolean =
if (null eq this) {null eq that} else {this equals that}
28.2 Writing an equality method
How should the equals method be defined? It turns out that writing a cor-
rect equality method is surprisingly difficult in object-oriented languages. In
fact, after studying a large body of Java code, the authors of a 2007 paper
concluded that almost all implementations of equals methods are faulty.
1
This is problematic, because equality is at the basis of many other things.
For one, a faulty equality method for a type C might mean that you cannot
reliably put an object of type C in a collection. You might have two elements
elem1, elem2 of type C which are equal, i.e., “elem1 equals elem2” yields
true. Nevertheless, with commonly occurring faulty implementations of the
equals method, you could still see behavior like the following:
var hashSet: Set[C] = new collection.immutable.HashSet
hashSet += elem1
hashSet contains elem2 // returns false!
Here are four common pitfalls
2
that can cause inconsistent behavior when
overriding equals:
1. Defining equals with the wrong signature.
2. Changing equals without also changing hashCode.
3. Defining equals in terms of mutable fields.
4. Failing to define equals as an equivalence relation.
These four pitfalls are discussed in the remainder of this section.
1
Vaziri, et al., “Declarative Object Identity Using Relation Types” [Vaz07]
2
All but the third of these pitfalls are described in the context of Java in the book, Effec-
tive Java Second Edition, by Joshua Bloch. [Blo08]
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index
Section 28.2 Chapter 28 · Object Equality 570
Pitfall #1: Defining equals with the wrong signature.
Consider adding an equality method to the following class of simple points:
class Point(val x: Int, val y: Int) { ... }
A seemingly obvious, but wrong way would be to define it like this:
// An utterly wrong definition of equals
def equals(other: Point): Boolean =
this.x == other.x && this.y == other.y
What’s wrong with this method? At first glance, it seems to work OK:
scala> val p1, p2 = new Point(1, 2)
p1: Point = Point@62d74e
p2: Point = Point@254de0
scala> val q = new Point(2, 3)
q: Point = Point@349f8a
scala> p1 equals p2
res0: Boolean = true
scala> p1 equals q
res1: Boolean = false
However, trouble starts once you start putting points into a collection:
scala> import scala.collection.mutable._
import scala.collection.mutable._
scala> val coll = HashSet(p1)
coll: scala.collection.mutable.Set[Point] =
Set(Point@62d74e)
scala> coll contains p2
res2: Boolean = false
How to explain that coll does not contain p2, even though p1 was added
to it, and p1 and p2 are equal objects? The reason becomes clear in the
following interaction, where the precise type of one of the compared points
is masked. Define p2a as an alias of p2, but with type Any instead of Point:
Cover · Overview · Contents · Discuss · Suggest · Glossary · Index