The big idea with OOP is "messaging". Right. What makes messaging useful is that the 'messagee' typically understands more than one different message. Because i

The big idea with OOP is "messaging". Right. What makes messaging useful is that the 'messagee' typically understands more than one different message. Because if it only understood one we couldn't take advantage of composing the interaction with them in different ways, as needed by the client. When we can do that we can also replace the messagee with an instance of some other conformant class, and thus we can reuse the client-side implementation of the interaction-protocol with many different types of recipients. Using the word "replace" here is easily misleading. A better word is "reuse". We don't typically DELETE the original service object at all. More likely we just REUSE the same client-code with different types of "service objects". The point is it can interact with many differently implemented service-objects that offer the same interface. If each class defined only one message it responds to, that wouldn't look like OOP, would it? It would look like FP where functions basically understand just one message, "Tell me your value!". Of course FP languages can simulate OOP and vice versa. Smalltalk for instance defines the class BlockClosure which understands the message #value: (among others). That means - "Tell me your value for this argument". But BlockClosure also understands other messages, like #asString, #class etc. That is OOP. We could say that OOP is a generalization of FP in this sense. Objects can do what functions do, calculate their "value" for a given argument. But this operation is explicitly declared as just one of the operations that object can perform. There is NO SPECIAL syntax for it, like "()" in FP languages. JavaScript can be characterized as a functional-object -language because its functions are first-class citizens but they can also have other operations than calculating their value. We can for instance "send the message" .toString() to them to get their source-code. You could have a "messaging conversation" with a JavaScript function (-object) like this: Me to function: "Hey tell me your source-code". The function returns it Me to my Helper -object: "Hey helper, does this source-code look secure?". Helper returns "Yes". Me to function: "OK, I trust you. Tell me your value for argument 42!". Function returns it. The conversation / messaging above could be reused with some other type of object without having to modify the client-side code at all. Summary: The essence of OOP is that objects can declare MULTIPLE messages they respond to, thus defining the protocol they can be interacted with. Many objects can support the same protocol of interacting with them, but provide a different implementation as to how they actually calculate some (or all) responses to the messages they get.