I seem not to fully understand how message-passing (say, in Java, in any OOP) is principally/much different from calling a method from another library or module (thinking procedurally like old pure C-style).
In modern OOP I also (just like old procedural C) call another block of code through another method (or chain of methods - if I call a library method, that method calls from its body other helper methods of the same library it belongs to) - so what's the difference exactly?
I do understand OOP, I've been using it many years. Of course code organization, private fields/methods (encapsulation) and bundling fields with methods within objects is very convenient - but it's just a way of organizing the code (one piece of code calling another).
So that fancy term "send a message" to object sounds to me like overestimated hype, really it boils down just to a more convenient way to organize code (allowed by OOP-language syntax), and nothing more revolutionary or very different ideologically.
Am I missing some importand idea or concept?
Wikipedia writes - message passing is a technique for invoking behavior (i.e., running a program) on a computer. The invoking program sends a message to a process (which may be an actor or object) and relies on that process and its supporting infrastructure to then select and run some appropriate code. Message passing differs from conventional programming where a process, subroutine, or function is directly invoked by name.
The invoking program sends a message and relies on the object to select and execute the appropriate code.
... invoke services on other objects without knowing or caring about how those services are implemented.
What is the BIG CONCEPTUAL difference exactly? Please pin-point it in a few sentences. There are tons of water around as I try to explore various concepts.
P.S. I don't have to pass some arguments because the object I call already contains necessary "arguments" (state) as its fields. OK, I see that. That't convenient and very different from C-procedural method call.
CodePudding user response:
The big conceptual difference between procedures and methods is polymorphism, which is achieved in object-oriented languages by late binding of methods.
When you call a procedure in a procedural language, you know at compile-time which block of code that procedure call will execute; that is, procedure calls are statically bound. But when you call a method in an object-oriented language, you (typically) do not know at compile-time which block of code that call will execute, because it could be overridden in a subclass; it could even be an abstract method with no implementation at the declaration site. In the procedural paradigm, the idea of an "abstract procedure" with no declared implementation is nonsensical.
This is sometimes referred to as "message passing" because the caller is only "sending a message" to the object, and does not necessarily know what procedure will be followed to handle that message. Note that late binding can also be achieved in non-OO languages, e.g. with first-class functions, so that when you call a callback function, you don't necessarily know at compile-time what that callback function will do. But the use of callback functions is not really part of the procedural programming paradigm, though they are supported by some procedural languages.