You mentioned 5 principles of OO:
but which one applies to "objects passing messages to one another"?
I think my point is that they don't (directly). Perhaps I could have been more clear. These are the five I've commonly heard when reading about OO. Like you've said, I think "OO is often enough misunderstood".
but none of this used a messaging infrastructure for internal communication
I'm sorry, I'm now realizing I could have been much more clear in my article about what I mean when I say "messaging". I do not mean to conflate it with event-driven or PubSub patterns. Those are two uses of messages, but don't (in my opinion) cover all messages.
At the most basic, a message consists of a name and parameters being sent to a particular object. Depending on how the object was constructed (from a class definition, from metaprogramming, from prototypes a la JavaScript) will determine what names of messages and what structure of parameters per name this object is capable of handling (any messages of an unknown name or poor structure should be considered an error). How do we usually define the names, parameters, and behavior for the messages? We use methods! To quote Wikipedia: "A method ... is a procedure associated with a message and an object." You can't not have done messaging in OO, because objects can't do anything besides receive messages.
put all the common stuff in a base class and derive all functional classes from this base
...
Inheritance and polymorphism are necessary to let you implement a code only once
We don't need inheritance to avoid duplicating code, just look at the way I got baseBoolean behavior into both objectOrientedTrue and objectOrientedFalse. That's not inheritance, I would say that's excellent composition support (I get the common functionality on my object, I can override it, and I could still get other common functionality on my object without worrying about being tied to inheriting from a single class with complete control over what should override what when confronted with name conflicts).
Looking back, almost every time I've used inheritance I would have been better served from either composition or from an interface definition separate from any class/method definitions (or a combination of the two). The main issue with inheritance is that it locks us into always pulling both behavior and interface and (in most languages) we can only inherit from one other class.
I'll take your example of rebuilding the database adapter for a banking app. Let's say we've historically had two databases: one old Relational DB and one to store JSON blobs. Being so different we had two adapters, one to interact with Old Relational DB and one for JSON. But hey, there's this new database that's both relational and capable of storing our JSON directly in the tables, that sounds nice...
...So we begin writing a single new adapter to replace the two old adapters. But with only single inheritance, I have a terrible choice: either duplicate some code across two classes to maintain the two interfaces or break the interface for one of my two use cases (forcing huge refactors across the whole codebase). Composition would let me pull in common behavior to two classes (one for each interface). Proper interfaces would let me have one class (containing the common behavior) and properly declare myself as implementing both interfaces the old adapters provided.
Luckily there are different ways to catch a tiger... If you find other methods more useful, why did you use inheritance then? It is an option, not an obligation.
I´m not sure if I would want to put the database adapter in a parent class. You do not need to inherit something to work with a class. You can just define an interface (for example a messaging system) and ask the database....
But maybe inheritance is a good way to define a messaging system for all your objects (ok, that was already mentioned :-)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think my point is that they don't (directly). Perhaps I could have been more clear. These are the five I've commonly heard when reading about OO. Like you've said, I think "OO is often enough misunderstood".
I'm sorry, I'm now realizing I could have been much more clear in my article about what I mean when I say "messaging". I do not mean to conflate it with event-driven or PubSub patterns. Those are two uses of messages, but don't (in my opinion) cover all messages.
At the most basic, a message consists of a name and parameters being sent to a particular object. Depending on how the object was constructed (from a class definition, from metaprogramming, from prototypes a la JavaScript) will determine what names of messages and what structure of parameters per name this object is capable of handling (any messages of an unknown name or poor structure should be considered an error). How do we usually define the names, parameters, and behavior for the messages? We use methods! To quote Wikipedia: "A method ... is a procedure associated with a message and an object." You can't not have done messaging in OO, because objects can't do anything besides receive messages.
We don't need inheritance to avoid duplicating code, just look at the way I got
baseBooleanbehavior into bothobjectOrientedTrueandobjectOrientedFalse. That's not inheritance, I would say that's excellent composition support (I get the common functionality on my object, I can override it, and I could still get other common functionality on my object without worrying about being tied to inheriting from a single class with complete control over what should override what when confronted with name conflicts).Looking back, almost every time I've used inheritance I would have been better served from either composition or from an interface definition separate from any class/method definitions (or a combination of the two). The main issue with inheritance is that it locks us into always pulling both behavior and interface and (in most languages) we can only inherit from one other class.
I'll take your example of rebuilding the database adapter for a banking app. Let's say we've historically had two databases: one old Relational DB and one to store JSON blobs. Being so different we had two adapters, one to interact with Old Relational DB and one for JSON. But hey, there's this new database that's both relational and capable of storing our JSON directly in the tables, that sounds nice...
...So we begin writing a single new adapter to replace the two old adapters. But with only single inheritance, I have a terrible choice: either duplicate some code across two classes to maintain the two interfaces or break the interface for one of my two use cases (forcing huge refactors across the whole codebase). Composition would let me pull in common behavior to two classes (one for each interface). Proper interfaces would let me have one class (containing the common behavior) and properly declare myself as implementing both interfaces the old adapters provided.
Luckily there are different ways to catch a tiger... If you find other methods more useful, why did you use inheritance then? It is an option, not an obligation.
I´m not sure if I would want to put the database adapter in a parent class. You do not need to inherit something to work with a class. You can just define an interface (for example a messaging system) and ask the database....
But maybe inheritance is a good way to define a messaging system for all your objects (ok, that was already mentioned :-)