CODEWITHSUNDEEP
scala
headexplodes
headexplodes

Reputation: 125

How to design immutable model classes when using inheritance

I'm having trouble finding an elegant way of designing a some simple classes to represent HTTP messages in Scala.

Say I have something like this:

abstract class HttpMessage(headers: List[String]) {
  def addHeader(header: String) = ???
}

class HttpRequest(path: String, headers: List[String])
    extends HttpMessage(headers)

new HttpRequest("/", List("foo")).addHeader("bar")

How can I make the addHeader method return a copy of itself with the new header added? (and keep the current value of path as well)

Thanks, Rob.

Upvotes: 2

Views: 140

Answers (1)

Edmondo
Edmondo

Reputation: 20080

It is annoying but the solution to implement your required pattern is not trivial.

The first point to notice is that if you want to preserve your subclass type, you need to add a type parameter. Without this, you are not able to specify an unknown return type in HttpMessage

abstract class HttpMessage(headers: List[String]) {
  type X <: HttpMessage
  def addHeader(header: String):X
}

Then you can implement the method in your concrete subclasses where you will have to specify the value of X:

class HttpRequest(path: String, headers: List[String])
    extends HttpMessage(headers){
    type X = HttpRequest
    def addHeader(header: String):HttpRequest = new HttpRequest(path, headers :+header) 
}

A better, more scalable solution is to use implicit for the purpose.

trait HeaderAdder[T<:HttpMessage]{
        def addHeader(httpMessage:T, header:String):T
}

and now you can define your method on the HttpMessage class like the following:

abstract class HttpMessage(headers: List[String]) {
      type X <: HttpMessage
      def addHeader(header: String)(implicit headerAdder:HeaderAdder[X]):X = headerAdder.add(this,header)    }
}

This latest approach is based on the typeclass concept and scales much better than inheritance. The idea is that you are not forced to have a valid HeaderAdder[T] for every T in your hierarchy, and if you try to call the method on a class for which no implicit is available in scope, you will get a compile time error.

This is great, because it prevents you to have to implement addHeader = sys.error("This is not supported") for certain classes in the hierarchy when it becomes "dirty" or to refactor it to avoid it becomes "dirty".

The best way to manage implicit is to put them in a trait like the following:

trait HeaderAdders {
    implicit val httpRequestHeaderAdder:HeaderAdder[HttpRequest] = new HeaderAdder[HttpRequest] { ... }
    implicit val httpRequestHeaderAdder:HeaderAdder[HttpWhat] = new HeaderAdder[HttpWhat] { ... }
}

and then you provide also an object, in case user can't mix it (for example if you have frameworks that investigate through reflection properties of the object, you don't want extra properties to be added to your current instance) (http://www.artima.com/scalazine/articles/selfless_trait_pattern.html)

object HeaderAdders extends HeaderAdders

So for example you can write things such as

// mixing example
class MyTest extends HeaderAdders // who cares about having two extra value in the object

// import example
import HeaderAdders._

class MyDomainClass // implicits are in scope, but not mixed inside MyDomainClass, so reflection from Hiberante will still work correctly

By the way, this design problem is the same of Scala collections, with the only difference that your HttpMessage is TraversableLike. Have a look to this question Calling map on a parallel collection via a reference to an ancestor type

Upvotes: 4

Related Questions