I think part of the problem is that we don’t. Or, at least, the different words and the different meanings don’t line up.
Smalltalk-style objects and Simula-style objects are very different things and so learning about Simula-style objects (e.g. from C++) is not very helpful trying to understand a Smalltalk-family language (JavaScript) and its object model. On the other hand, Smalltalk-style objects and Erlang-style processes are very similar (though with different opinions about whether control flow should be synchronous or asynchronous by default), yet Erlang processes and OS processes are very different.
JavaScript is a Smalltalk family language, so looking for examples in Simula-family languages will confuse you. If you want to understand OOP, listen to the person who coined the term: Alan Kay.
I think the problem is in any real world use of polymorphism, the class abstraction only pays for itself when the program reaches a certain threshold of complexity, but if you actually had that level of complexity in the example, it would distract from what you’re trying to teach. So you end up with uses of classes that are completely non-idiomatic because why wouldn’t you just use an if-statement instead of polymorphism here?
In D, for example, 1 through 3 are properly represented by struct values rather than objects. (In C++ terms, non-virtual final value objects, or plain old data objects.) A struct, or record, is just a named type consisting of a set of variables, called members. This creates a clearer demarcation where the machinery of object orientation, ie. inheritance, hiding, accessors, constructors, vtables etc., is only used in case 4 where they’re actually needed. JS, of course, does not have struct types. I think it is probably easier to understand (most) JS objects by learning about structs, rather than classes.
If we had different names for objects in every language this stuff would be 100x easier.. but then we’d have 100 names for objects.. :(
I think part of the problem is that we don’t. Or, at least, the different words and the different meanings don’t line up. Smalltalk-style objects and Simula-style objects are very different things and so learning about Simula-style objects (e.g. from C++) is not very helpful trying to understand a Smalltalk-family language (JavaScript) and its object model. On the other hand, Smalltalk-style objects and Erlang-style processes are very similar (though with different opinions about whether control flow should be synchronous or asynchronous by default), yet Erlang processes and OS processes are very different.
JavaScript is a Smalltalk family language, so looking for examples in Simula-family languages will confuse you. If you want to understand OOP, listen to the person who coined the term: Alan Kay.
Because a lot of people who teach programming are academics who don’t have the years of experience working on real codebases on real problems.
Because if you try to use a non-physical example, you risk alienating half the class who don’t immediately grok what a
TextElementis.I think the problem is in any real world use of polymorphism, the class abstraction only pays for itself when the program reaches a certain threshold of complexity, but if you actually had that level of complexity in the example, it would distract from what you’re trying to teach. So you end up with uses of classes that are completely non-idiomatic because why wouldn’t you just use an if-statement instead of polymorphism here?
In D, for example, 1 through 3 are properly represented by struct values rather than objects. (In C++ terms, non-virtual final value objects, or plain old data objects.) A struct, or record, is just a named type consisting of a set of variables, called members. This creates a clearer demarcation where the machinery of object orientation, ie. inheritance, hiding, accessors, constructors, vtables etc., is only used in case 4 where they’re actually needed. JS, of course, does not have struct types. I think it is probably easier to understand (most) JS objects by learning about structs, rather than classes.