One of the best expedient to explain the interactions between Actors is thinking as method calls. It is useful to look at in this way during the design phase because it helps to better structure the code.

A method is identified by the name, the arguments and the return value. The first describes the operation, the second the data necessary to complete it and the last one the result.

The method is also defined in a class or and interface that defines its context.

class Contact {
  public boolean addNumber(String number) {
    ...
  }
}

For example a method without name that takes a string and returns a boolean can be very generic, while the method addNumber is more specific. The same method name can also have different meaning if defined in a different class.

A message in the Actor model is an immutable class that is sent to an actor. The concept is the same of method: the class name is the method name and the properties are the method arguments. The actor is context of the message like the class is for the method.

Method Name      = Message Class Name
Method Arguments = Message Class Properties
Method Class     = Actor

The message response is similar to the return value but contains also information about the origin of the message (operation and actor).

Four lessons

1. The method name should be meaningful, the message name should be the same.
2. There are generic methods (toString), there are generic messages (PoisonPill). All the specif messages to an actor should be used only by the actor (into the companion object).
3. The method should do one thing, the actor should treat a message in the same way. Avoid to use parameters meaning different operations, like boolean switcher. Create instead another message as you would create another method.
4. The result of a message tells also the origin of the messages. Avoid generic or shared messages, use actor specif result messages.