Java将OOP变成了可变性驱动（mutability-driven）的开发模式[1]，而函数式编程则着重强调不可变性，而这两种极端的方式其实都是有问题的。如果每样事物都是可变的，那么我们就需要妥善处理可见性和竞争条件。而在一个真实的应用程序中，也并非所有事物都是不可变的。即使是纯函数式语言也提供了代码限制区，在该区域内允许出现带副作用的逻辑以及按顺序执行这些逻辑的方法。但无论我们倾向于哪种编程模型，避免共享可变性都是毋庸置疑的。
共享可变性——并发问题的根源所在——是指多个线程可以同时更改相同的变量。而隔离可变性——一个可以消除大部分并发问题的不错的折衷方案——是指任意时刻有且只有一个线程（或角色）可以访问某个可变变量。
在OOP中，由于对象的状态都被封装在对象中，所以只有实例函数才能够操作对象的状态。然而不同的线程可以同时调用这些函数，从而导致并发问题的发生。在基于角色（actor）的编程模型中，我们只允许一个角色（actor）操作对象的状态。因此，即使整个应用程序是多线程的，那些角色（actor）本身也都是单线程的，所以也就不会有任何可见性和竞争条件相关的问题。虽然角色（actor）都可以发出操作执行请求，但它们却无法接触到其他角色（actor）托管的可变状态。
我们在使用基于角色（actor）的模型进行编程时，往往会采取与普通的面向对象编程不同的设计方法。即将问题拆分成若干个可计算的异步任务，并将它们赋予不同的角色（actor）。其中，每个角色（actor）只负责执行分配给自己的那部分任务。这样我们就可以将任意可变状态限定在至多一个角色（actor）当中（见图 8‑1）。此外，我们还需要保证在角色（actor）之间传递的消息都是完全不可变的才行。
在这种设计方法中，我们令每个actor都负责解决问题的一个组成部分，而它们所接收的数据则都当作不可变对象来处理。一旦完成了分配给自己的任务，这些角色（actor）就会把处理结果封装到不可变对象中并返回给调用角色或其他特定的后置处理（post-processing）角色。我们可以将这种方式想象为OOP进化版，即我们让可变且活跃的对象分别运行在属于自己的线程里。在这种模式下，对对象进行操作的唯一方法是将消息传递给它们而不是直接调用其成员函数。
[1] 在这个问题上Java还有其他同案犯，所以我们不应该把所有责任都归咎于Java。