Actor based classes with or without interfaces

Question

I am playing around with Scala right now and tried to figure out some best practices about how to design classes. (Trying Scala since a week or so.)

Since my Erlang time I am a huge fan of message passing and actor based software. In most Scala examples actor classes are implemented like this:

object Foo
object Bar
class MyActor extends Actor {
  def receive = {
    case Foo => ...
    case Bar => ...
    case _ => ...
  }
}

But what I learned from my object oriented (interfaces and polymorphism) carrier tells me that this concept is not very flexible.

MyActor could be replaced by MyAdvancedActor but there is no contract which defines which messages an MyActor implementation needs to implement.

When I think about writing Actors in Scala I tend to write a trait which specifies some methods. The MyActor implementation needs to implement this methods in which the can send its own private messages to itself. With this approach we have a specified interface and can replace the MyActor implementation in a type-safe manner.

In my time of reading scala tutorials and examples I did not come across such an class design. Is it not common sense or are there better ways in doing this in Scala? Or are these tutorials just to small to cover such a topic?

Answer 1

Common practice is to use an algebraic data type in such cases: you could create a sealed base type for all messages like this:

sealed trait MyActorMessages
object Foo extends MyActorMessages
object Bar extends MyActorMessages

But this kind of contract is not enforced by compiler. You could use use Typed Channels to enforce this contract:

class MyActor extends Actor with Channels[TNil, (MyActorMessages, MyActorReply) :+: TNil] {
  channel[MyActorMessages] { (req, snd) ⇒
    req match {
      case Foo  ⇒ ...
      case Bar ⇒ ... // You'll get a warning if you forget about `Bar`
    }
  }
}

Compiler will force you (with warning) to process all possible message types (in this case all subtypes of MyActorMessages), and senders will be forced to send only valid messages using <-!- method (with compilation error).

Note that senders can also use unsafe method ! to send invalid messages.