Chapter 3. Best Practices
I have been fortunate enough to have been using Actors and Scala since 2009, but I have also experienced a great deal of pain from having made many mistakes in that time. Here are some important rules to follow for actor-based development, though many of the rules are applicable to asynchronous coding in general.
Actors Should Do Only One Thing
One of the hardest things to do in software development is to design a system based on primitives. By that, I mean the lowest level of functional decomposition we can achieve. With actors, we have the ability to define very elemental abstractions of functionality, and we want to take advantage of this. So how do we do it?
Single Responsibility Principle
Robert Martin, also known as “Uncle Bob,” taught us in Agile Software Development (Prentice Hall) that we should try to isolate responsibilities into unique classes. In doing so, we avoid conflating what an object-oriented class should do and keep the implementation simple. Bob believes, and I agree with him, that each class should be concise and small, giving you more flexibility for its usage. The more you add to it that is outside of its base role, the more you have extra functionality and code for usages that may not require them.
With actors, I believe this to be particularly true. It is very easy to make an actor perform additional tasks—we simply add new messages to its receive block to allow it to perform more and different kinds of work. However, doing so limits ...