Over the last couple of weeks I did an OO programming experiment. I call it the Erlang design pattern. It is based on the Actor model but goes some steps further. At its core just like the Actor model there are active entities (objects) that have a thread and a message queue with the thread waiting on the message queue to do some stuff.

The Erlang design pattern extends the Actor model by first dividing the software program into active (actors, that have their own thread) and passive (objects, whose methods are called by other actors) objects.
Second, I enforced that all methods of an active or passive object are always called by the same thread context (e.g. actor). So for each object there is no shared state between different thread contexts anymore. Two different objects of the same class could as a matter of course be used by two different actors.
Third, if two or more actors want to share data they have to explicitly do this via message passing. To avoid a lot of copying I shared data using smart pointers in C++ and references in Java and C#. When one actor sends such a data structure to another actor it loses its reference to that data structure to make sure that it is only owned by one actor at a time (see also Microsoft Singularity's exchange heap).

Building software systems using the Erlang design pattern was very interesting because it helped to write concurrent, modular, scalable and readable code :-). Maybe you will try it at your next code retreat.
Of course there also were some quirks. E.g. I couldn't use my C++ closures (which I really like) anymore because they delegate methods of an object from one thread context to another.
To sum this up, the Erlang design pattern was an interesting experiment which I will most probably not use every day in its pure form. But it helps to better understand how ideas of functional programming result in modular, scalable and readable (OO) software systems.

For C++, I used my Android messaging and concurrency framework to play around with the Erlang design pattern and for Java I just used the Android SDK.

Of Joe Armstrong's Erlang design principles, the Actor model "solves" the first and third point. The Erlang Design pattern also "solves" the second point and goes a step further on the third one.

• The world is concurrent.
• Things in the world don't share data.
• Things communicate with messages.
• Things fail.

Now the task is to solve the fourth point in an elegant way.
To achieve to same degree of concurrency as Erlang does with its lightweight processes one definitely needs to build its own virtual machine and OS thread abstractions.
But for smartphone and tablet software development one will most probably not need that degree of concurrency and is able to stick with OS threads :-).

Source:http://himmele.blogspot.com/2012/02/erlang-design-pattern.html