This isn't really an OO pattern, as the rest of the post demonstrates. It's just a pattern that applies across most any language where you can make a distinction between an interface/typeclass or whatever, and a concrete type.
This isn't really an OO pattern, as the rest of the post demonstrates. It's just a pattern that applies across most any language where you can make a distinction between an interface/typeclass or whatever, and a concrete type.
This is the essence of OOP.
"The notion of an interface is what truly characterizes objects - not classes, not inheritance, not mutable state. Read William Cook's classic essay for a deep discussion on this." - Gilad Bracha
https://blog.bracha.org/primordialsoup.html?snapshot=Amplefo...
Objects, but not OO. OO takes the concept further — what it calls message passing — which allows an object to dynamically respond to messages at runtime, even where the message does not conform to any known interface.
Dynamic typing is a necessary precondition for OO[1], but that is not what defines it. Javascript, for example, has objects and is dynamically typed, but is not OO. If I call object.random_gibberish in Javascript, the object will never know. The runtime will blow up before it ever finds out. Whereas in an OO language the object will receive a message containing "random_gibberish" and it can decide what it do with it.
[1] Objective-C demonstrated that you can include static-typing in a partial, somewhat hacky way, but there is no way to avoid dynamic-typing completely.
Go channels share some basic conceptual ideas with message passing, but they don't go far enough to bear any direct resemblance to OO; most notably they are not tied to objects in any way.