When people usually talk about type classes in languages like Haskell and Scala they tend to be thinking of highly generic concepts like Ordering or Numeric operations. However, in some recent experiments with Haskell I have found that type classes can be very useful for more concrete things. When used appropriately they can lead to more loosely coupled software that is more flexible and easier to change.
I Just Met You, This Is Crazy, Here's My Number, Call Me Function?
As an example, let's consider a telephone number. Fairly simple right, it's a string of digits?
def sendMessage(toNumber: String, theMessage: Message)
Or perhaps we should create a type alias to give us some better info and scope for change:
type TelephoneNumber = String def sendMessage(toNumber: TelephoneNumber, theMessage: Message)
But wait, I'm trying to build a library that sends messages to telephones and I need to know much more about a telephone number than this 'stringly' typed data is able to tell me. Things like:
- Is it in international format?
- What's the country prefix code?
- Is it a mobile number or a landline number?
- What is the area code?
- Is it some premium rate number?
- and so on…
The Naive Solution
It's clear that my 'stringly' typed representation is not sufficient for this task unless I want to encode a whole load of rules about the world's telephone numbering systems into my library (believe me when I say I don't!). So, a naive approach would be to introduce a new type that holds the information in a more usable format. Something like:
case class TelephoneNumber(countryCode: String, areaCode: String, number: String, isMobile: Boolean, isLandline: Boolean, …)
Unfortunately, this approach suffers from a whole host of problems, including:
- If I build my library implementation against this class then I can't easily change implementation details without breaking the API
- If I copy from an instance of this type into an internal representation then I have a lot of duplication and extra code to test
- If a client uses this type in their domain model they are tightly coupled to my library (and also a specific version of it)
- If a client copies from their own representation into an instance of this type there is more duplication and extra code to test
A More Object-Oriented Approach
So, how do we deal with this? Well what we need to do is separate the behaviour of a telephone number from its actual data representation. In an object-oriented language we would do this by introducing an interface (or in Scala, a trait):
trait TelephoneNumber {
def countryCode: String
def areaCode: String
def number: String
def isMobile: Boolean
def isLandline: Boolean
// and so on...
}
Internally in my library I write all my code against this interface without any care as to how the underlying telephone number data is structured. Client applications are free to implement telephone numbers in whatever way they wish, provided they also implement the interface that exposes the behaviour that my library needs. Yay, problem solved. Or is it? There's still one problem in this object-oriented approach: somewhere in the client code there must be a class that implements the TelephoneNumber interface. This is problematical in a number of ways:
- The class hierarchy of the client domain model is still quite tightly coupled to my library
- It might not be possible to modify an existing domain model to implement the TelephoneNumber interface (no access to source code, coupling restrictions etc.)
- If the client domain represents telephone numbers as Strings then this class can be extended to implement the interface
Both of the last two points would result in needing to implement the same sort of mapping layer to copy between representations that we already said lead to duplication and extra code to test.
How Haskell Does It
So, in a purely functional language that doesn't have the concept of interfaces how do we solve this problem. Enter the Type Class. These clever little beasties provide a mechanism whereby the required behaviour is captured as a series of function definitions (with possible implementations if available). For example:
class TelephoneNumber a where
countryCode :: a -> String
areaCode :: a -> String
number :: a -> String
isMobile :: a -> Bool
isLandline :: a -> Bool
...
So far this looks pretty much like our interface definition above except that each method takes an instance of type 'a' as a parameter and returns the result. However, the clever bit comes in that we can implement the type class for any type in Haskell without needing to modify that type in any way. For example, we could easily implement it for Strings:
instance TelephoneNumber String where
countryCode s = ...
areaCode s = ...
...
Or our client code could define its own telephone number data type and an implementation of the type class along side it:
data UKTelephoneNumber = ...
instance TelephoneNumber UKTelephoneNumber where
countryCode t = ...
...
The final change is then that we have our library function require that something implementing the type class is provided rather than some concrete data type:
sendMessage :: (TelephoneNumber t) => t -> Message -> IO ()
sendMessage to msg = do
...
let cc = countryCode t -- call function on the type class passing the instance we have
...
In this Haskell solution we have neatly decoupled the behaviour that our library requires of telephone numbers from the data type used to represent them. Also, any client code of our library does not need to couple its data structures/types directly to the library. They can define and modify them in any way they like. All they need to do is keep the instance of the type class up-to-date.
And Finally, A Better Scala Solution
As I have hopefully shown, the Haskell solution to the problem is both elegant and leads to cleaner, more loosely coupled code. So can we do something similar in Scala? Well, yes we can because Scala also supports type classes. They are a bit less elegant than Haskell, but they work just fine. First, we need to change the TelephoneNumber trait into a type class:
trait TelephoneNumber[T] {
def countryCode(t: T): String
def areaCode(t: T): String
def number(t: T): String
def isMobile(t: T): Boolean
def isLandline(t: T): Boolean
// and so on...
}
Note that all we have done is added a type parameter and modified all the functions to take an instance of that type. Notice that it's now almost identical in structure to the Haskell equivalent. Next we need an implementation of this type class. Let's define one for String:
object TelephoneNumber {
object StringIsATelephoneNumber extends TelephoneNumber[String] {
def countryCode(t: String) = ...
...
}
implicit def TelephoneNumber[String] = StringIsATelephoneNumber
}
I've put the implementation inside a TelephoneNumber object. If you are defining your own types, convention is usually that the type classes go in the companion object (e.g. for a case class UkTelephoneNumber the type class implementations would be in the UkTelephoneNumber companion object). This insures that the type class instances are always in scope when the type is used.
Finally, lets update our sendMessage function to work with type classes:
def sendMessage[T : TelephoneNumber](toNumber: T, theMessage: Message) = {
...
val telNo = implicitly[TelephoneNumber[T]]
val cc = telNo countryCode toNumber
...
}
Note the use of the context bound symbol ':' plus the implicitly function to define the need for and access to the correct instance of the type class.
So there we have it, an elegant Scala solution the overcome all of the coupling problems inherent with the object-oriented approach of implementing a required interface. When should you use this? My opinion is anywhere that two system components communicate, where that communication can be defined in terms of behavioural functions rather than actual data and where you want to minimise the coupling between them and the leaking of types from one component to another.
