> I have always struggled with OOP and have never found it a natural way of programming.
'Modern' OO languages are never natural. Actors are more natural.
A typical day-to-day Java Spring web service workflow:
1. Receive request in Controller.
2. Get FooRepository in through DI.
3. Read a user from UserRepository (behind UserRepository is a SQL database).
4. Get another stuff from DI, say EmailService.
5. Call EmailService to send email based on properties of Foo.
6. Return OK to the client.
Let's see what's in the example:
1. Controller/Repository/Service/Container/Request are not objects. They are made up engineering concepts.
2. The User seems to be a reasonable object, but actually, it's not. It's dead, it only temporarily revives when you summon it from the database, then becomes dead again. It does not know how to do things, it cannot
even repeatedly check the current time and then send email itself just like any person in the real world. In contrast, actors are mostly long live in-memory processes and can tell anyone do anything at any time.
Why it's bad or I should say, redundant?
1. Consider Controllers, Services or other objects, if you have 100 methods on a single class it's considered a code smell. Then guys in the project will refactor it to 10 different made up classes with 10 methods each. The name of the classes and their relationships to methods are totally arbitrary, 10 people will yield 10 totally different results.
2. The User is just data, there is no point in make them objects. A) The OO has an in-memory reference system but it's awkward when combining with database entity ids or any kind of distributed environment. B) OO class is redundant because struct or algebra data type (ADT) will do, and they have much better semantics on equality. C) When it comes to modeling OO is more awkward than ADT (because there's no sum type). When it comes polymorphism (the main advertised aspect of OO) the sub-type polymorphism is more awkward than parametric polymorphism.
Personal conclusion (at least in the Web scenario): Functional style (ADT + functions) is simpler. Actor style is intuitive for the real-time web system. 'Modern' OO is both awkward and redundant because no one is doing OO in web programming anyway.
'Modern' OO languages are never natural. Actors are more natural.
A typical day-to-day Java Spring web service workflow:
1. Receive request in Controller.
2. Get FooRepository in through DI.
3. Read a user from UserRepository (behind UserRepository is a SQL database).
4. Get another stuff from DI, say EmailService.
5. Call EmailService to send email based on properties of Foo.
6. Return OK to the client.
Let's see what's in the example:
1. Controller/Repository/Service/Container/Request are not objects. They are made up engineering concepts.
2. The User seems to be a reasonable object, but actually, it's not. It's dead, it only temporarily revives when you summon it from the database, then becomes dead again. It does not know how to do things, it cannot even repeatedly check the current time and then send email itself just like any person in the real world. In contrast, actors are mostly long live in-memory processes and can tell anyone do anything at any time.
Why it's bad or I should say, redundant?
1. Consider Controllers, Services or other objects, if you have 100 methods on a single class it's considered a code smell. Then guys in the project will refactor it to 10 different made up classes with 10 methods each. The name of the classes and their relationships to methods are totally arbitrary, 10 people will yield 10 totally different results.
2. The User is just data, there is no point in make them objects. A) The OO has an in-memory reference system but it's awkward when combining with database entity ids or any kind of distributed environment. B) OO class is redundant because struct or algebra data type (ADT) will do, and they have much better semantics on equality. C) When it comes to modeling OO is more awkward than ADT (because there's no sum type). When it comes polymorphism (the main advertised aspect of OO) the sub-type polymorphism is more awkward than parametric polymorphism.
Personal conclusion (at least in the Web scenario): Functional style (ADT + functions) is simpler. Actor style is intuitive for the real-time web system. 'Modern' OO is both awkward and redundant because no one is doing OO in web programming anyway.