Actor model vs object oriented model

Question

I searched in the web for a long time and couldn't find the concrete disadvantages of object oriented model which are overcome in Actor model. Please help me with some pointers and explanations on it.

Thanks in advance.

Sewn

anthonylebrun.silvrback.com/actors-vs-objects – Judgment

@Judgment Great link.Thanks – Sewn

related: #15148424 – Deanedeaner

Answer 1

Disadvantages of OO model:

1. Traditional OOP languages weren’t designed with concurrency. It was very easy to introduce race conditions since it was using a shared state.
2. The programmers had to identify and fix all possible problem areas by using locking mechanisms.
3. Locking is easy to implement for simple programs. But as the programs got complex, the implementation of locking has also become complex.

Actor model overcomes the problem by using share nothing model so that concurrency is not affected and locking mechanism is not needed.

Sewn

Answer 2

The term Object Oriented Programming originally came from Alan Kay and Smalltalk. It emphasized messaging passing as its primary feature. This is what OOP originally meant.

Once C++ and Java came along the term object oriented programming took on a slightly different meaning. It morphed to what some people call "class-oriented programming".

The Actor model re-emphasizes the originally OOP concept of message passing being the core fundamental.

Actor model pros:

• Works better in a distributed system
• Simpler to understand architecturally in many cases
• Models real world phenomena / complex systems with multiple "actors"
• Largely compatible with functional programming styles (see Smalltalk)

Actor model cons:

• Harder to reason about an algorithm because it doesn't exist in just one place. It's gets split across different actors / files and you have to chase it down and follow code.
• Similarly, multiple algorithms can be mixed among multiple actors. So you might go to a file and read an Actor's code to follow the algorithm but get confused because other algorithms are also mixed into the same Actor.
• Traditional semaphore–style locking not possible. Must use STM–style which can be more complicated.
• Harder to get "return values". The Actor model is "fire and forget". You have to figure out how to get "return values" back to the original requester. This adds lots of overhead because now you have to set up a way to receive it and pass the context (uniqueId / taskId) through the entire system. You also need to manage the state to hold that information around until the "response" comes back. Without the actor model they would just be local variables in a block scope.

Cricoid

This is actually a great addendum to the answer from @SugaRaj – Biddick

except that it was developed in Simula-67 where multiple objects had their own lives simultaneously, which was repeated only in Erlang. While Smalltalk only allowed a message to change internal state of the object - exactly similar to C++/Java – Fireball