On 9/26/2018 at 11:59 PM, noizex said:
And I'd gladly hear about the "right way" to do this, because if ECS is bad, bad OO is bad, then what's good? Links, blog posts, articles, code samples please. I'm a bit tired of hearing one side advertising some ultimate solution to everything and more (which looks kinda ugly and is probably just as unmaintainable as anything else as soon as it grew to something bigger than some bazzilion of sprintes rotating at once on the screen), and another side bashing this, and mentioning some proper OO code which I obviously had never an honour to see.
Umm... There's no posts before (or after?) yours in the thread bashing OO or ECS.
I was critiquing the "traditional OOP" code in the talk, which is presented as being bad code - he deliberately starts with badly written code to simulate a typical real world project. It's frustrating to see every ECS presentation follow this same pattern of comparing itself against bad code of a different style instead of good code. It feels disingenuous that an apples to apples comparison is never used. That's not a slight against the design - it's complaint against the promotion technique.
As for the OO code being bad- it uses OOP language features, but does not follow OOD design rules. This might be "typical" of code in the wild, but it's a bit of a misnomer to call it "traditional OOP". I'd call it "typical OOP bullshit". It's really great that Aras included a git repository and commits for each step - if you're interested I might take the time to do a blog, starting from the initial bad code, and fixing it to actually follow OOD rules.
A short version off the top of my head though - "virtual void Update" is an SRP violation. Dynamic cast is an LSP violation. It violates the principle of preferring composition over inheritance. The broad base classes are ISP violations. It needlessly reimplements language features with runtime code.
Basically, it disregards OOD theory, and abuses OOP language features in ways that the theory says not to... i.e. There's a difference between using OOP language features and using OO design rules. Yet, unfortunately it is 'typical' and 'common' to see such things. That's why I'm critiquing it - instead of encouraging people to actually learn the existing theory, these kinds of presentations encourage you to just move on to the next fad without learning any of the decades of background material.
Likewise, ECS itself is also just an ad-hoc reinvention of relational data modelling. By presenting it as some new pattern, it discourages new learners from actually bothering to study the underlying decades of formal study in relational techniques.
Aras at least hints at this when he says that an entity is a primary key, which is far better than what most ECS talks do.
TL;DR: study OOD, study SOLID, study relational data modelling, study object modelling techniques in general. There's decades of formal computer science research here. Most code that uses OOP language features doesn't actually follow OO theory. ECS is not a formal pattern, it's just a new buzzword name for using relational modelling, except with the added restriction that you can only ever have a single primary key (the entity ID), which isn't a necessary restriction to adopt. Relational is great. Procedural code is great. DOD ideas are great. OOD ideas are great. OOP tools are often used badly, bit not necessarily. ECS frameworks are often bad too, but not necessarily. Relational frameworks power a boatload of the internet (obviously useful). Bad code in any paradigm is bad.
Basically if you fix the obvious OOD rule breakages in the original code, it's smaller/simpler than the final "ECS" version, uses less memory, initializes faster, and only updates slightly slower (due to no DOD cache optimization pass being done, yet)... This is a much more apples to apples comparison between OOD and ECS, both starting from the same "incorrect OOP" baseline:
