trait

A Scala Factory Pattern example

Here’s a small example of how to create a Factory Pattern in Scala. In the Scala Cookbook I created what some people might call a simple factory and/or static factory, so the following code is a much better implementation of a true OOP Factory Pattern.

The factory classes

I don’t have too much time to explain the code today, but here are the classes that make up the factory, including a set of “animal” classes along with a DogFactory and CatFactory that extend an AnimalFactory trait:

What def, val, and var fields in Scala traits look like after they’re compiled (including the classes that extend them)

Table of Contents1 - def field in trait2 - val field in trait (abstract)3 - val field in trait (concrete)4 - var field in trait (abstract)5 - var field in trait (concrete)6 - An abstract class in the middle7 - A trait in the middle8 - Summary

I generally have a pretty good feel for how Scala traits work, and how they can be used for different needs. As one example, a few years ago I learned that it’s best to define abstract fields in traits using def. But there are still a few things I wonder about.

Today I had a few free moments and I decided to look at what happens under the covers when you use def, val, and var fields in traits, and then mix-in or extend those traits with classes. So I created some examples, compiled them with scalac -Xprint:all, and then decompiled them with JAD to see what everything looks like under the covers.

I was initially going to write a summary here, but if you want to know how things work under the hood, I think it helps to work through the examples, so for today I’ll leave that as an exercise for the reader.

An example of stackable modifications in Scala

As a brief note today, here’s an example of stackable modifications in Scala.

What is ‘super’ in Scala when you mix in traits?

Lately I was curious about what super means when you mix Scala traits into a class or object. A simplified answer is that super refers to the last trait that’s mixed in, though I should be careful and note that this is an oversimplification.

This can be demonstrated in an example that uses both inheritance and mixins with traits. Given this combination of traits and classes:

A good reason to use sealed traits and classes in Scala

This scala-lang.org documentation page shares a good reason to use “sealed” traits and classes: When you created sealed traits, the compiler can easily tell all of the subtypes of your class or trait, and as just one benefit, you don’t need to add a default, “catch-all” case in your Scala match expressions.

This is a page from my book, Functional Programming, Simplified

On Using `def` vs `val` To Define Abstract Members in Scala Traits

When I update the Scala Cookbook, I need to update Recipe 8.2, “How to use abstract and concrete fields in Scala traits.” That recipe is written particularly with an OOP developer in mind, and I didn’t write about handling the same situation from an FP perspective.

Scala best practices (idioms) (from the Scala Cookbook)

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is the introduction to Chapter 20, _Idioms_ (Scala best practices).

When I first came to Scala from Java, I was happy with the small things, including eliminating a lot of ;, (), and {} characters, and writing more concise, Ruby-like code. These were nice little wins that made for “a better Java.”

How to wrap Scala traits so they can be used from Java code

This is an excerpt from the Scala Cookbook (partially modified for the internet). This is Recipe 17.7, “How to write Scala traits so they can be used from Java code.”

Problem

You’ve written a Scala trait with implemented methods and need to be able to use those methods from a Java application.

Solution

You can’t use the implemented methods of a Scala trait from Java, so wrap the trait in a class.