Reputation: 6754
I'm very new to Akka. I'm designing a modular system in Akka, and I'm looking for a way to define an API for each module.
Normally in Java I'd write a bunch of beans and some interfaces that accept and produce those beans. From what I gather, in Akka Message types replace the beans, and there seems to be no equivalent for an Interface (or something to help the compiler enforce some "what happens when" or "what can happen when" contract).
I would welcome any advice or best practice on what is the best way to write the most coherent API. If the compiler can understand it, it's a serious bonus.
Upvotes: 1
Views: 108
Reputation: 15472
The API exposed by an Actor (or a collection of collaborating Actors) is defined by the set of message types that it accepts. My recommendation is to keep these message classes close to the Actor, e.g. as static inner classes of the UntypedActor class (for Java) or in the Actor’s companion object (for Scala). For larger actor hierarchies implementing a single interface I would recommend placing all the message classes with the “head actor” (the entry point to the hierarchy) or in a separate class that has a descriptive name and is otherwise empty. Having the as top-level classes can easily lead to name-clashes that can in Java only be resolved by using fully-qualified class names.
The compiler can currently not yet help you in avoiding the mistake of sending the wrong message to an ActorRef because that reference is oblivious to the kind of actor it represents. We are researching ways to tackle this problem, you can take a look at the TypedChannels experiment (Scala only) and later this year we will start working on a simpler solution that also supports Java (codename “Akka Gålbma”, see the roadmap).
Upvotes: 1