It wouldn't be the first time… https://loup-vaillant.fr/articles/deaths-of-oop
Using ECS means totally eschewing things like encapsulation and inheritance. You stop grouping functions and methods together. You basically have "free records" and "free procedures" (or "free methods" if the language requires classes, Kingdom of Nouns style). ECS is a procedural/functional paradigm.
You can argue that this is not OOP anymore, and guess what: I'll probably support you on that! :)
This is not a trivial question because class-instances are basically collections of Functions, and Functions can return class-instances. So a trivial answer would be: "It does not matter, you can do everything with either one".
No, you shouldn't do everything with both, you should do some specific types of things with classes and other types of things with functions. But what?
I've come to this rule-of-thumb: Use classes only to represent and encapsulate data, use functions to process and transform class-instances.
In practice this means classes should not have methods which take arguments!
Classes are still truly useful over plain records, because a class abstracts over what data is stored, and what are the names by which it is accessed, and whether the methods return a stored field or a calculated one.
The idea that "Everything is an instance of a Class" as in Smalltalk is a bit flawed, or at least too trivial. Except of course it is also true that Functions are objects. (And in Smalltalk you can use BlockClosures, which really are "functions").
This division of design makes it easier for me to think about the structure of the whole application. I no longer have classes for everything. Instead I have classes which represent data, and a set of functions which do the processing of those class-instances.
Why is this good? Because classes are, and easily become complicated, since they can have many methods, they can have static vs. instance-methods, and methods can be inherited and you can even use the 'super' to add to the confusion. So therefore if you can find a way to force your classes to be as simple as possible, this is it. Don't make them do complicated things since they are complicated to start with.
Dividing the design into two parts, classes + functions, divides the complexity of the whole app into two parts, each of which contains about 1/2 of the complexity of the whole app. The complexity is now data-complexity PLUS function-complexity whereas with use-only-classes -approach the app-complexity would be more like data-complexity TIMES function complexity.
Keep data (= classes) and functions separate. Divide and conquer complexity.
The part about classes only acting on themselves resonates heavily with me. To me it's the same with components in frontend apps: the more independent they are, the better.
I'm probably never going to be copy-pasting my classes and components into other apps, but a good class/component should be copy-paste-able without needing many dependencies. This avoids the "banana gorilla jungle problem", as named by Joe Armstrong.
"Free Functions" also help with keeping those classes even more self-contained and decoupled: you can use Function types for callbacks and things like that, instead of having to couple the class to some other class or interface. The only thing the class has to worry about is that the function conforms to the type.
-
"Keep data (= classes) and functions separate. Divide and conquer complexity."
Yep, 100% agree. Amen to that.
In a typical OOP design there would be no clear rules as to who can depend on whom and whom not.
Agreed. Arrays of Structs is not the part that is really incompatible.
The part that clashes a bit with traditional OOP is ECS, where data and code are meant to be kept separate. But of course I'm talking about very traditional OOP. It is entirely possible to use an OOP languages + classes to implement ECS. It's just not gonna be "traditional".
EDIT: To quote your other reply: "records don’t have to identify strongly with a class hierarchy".