I am not qualified to answer this question specifically as I am new to ECS, but let me give you an example from the embedded systems world that I have already studied a lot of time…
Imagine, you want to build a driver API for mice, a standard mouse will have 3 buttons, 1 scrollball, and a laser sensor. Well, you can just bump a
StandardMouse class with all these stuff, but here is what happens when the market releases another mouse with a forward/backward option, you will have to extend the StandardMouse to add the new features, let’s say
OfficeMouse extends StandardMouse. Then, the market is back on your shoulders with the DPI feature, so by following this inheritance pattern, you decided to extend the OfficeMouse to create the DPIMouse, but here is the burden; a mouse with DPI, but doesn’t support forward/backward options, this will lead to an overwhelming internal complexity which is an anti-pattern; for example: creating boolean flags (a flag
hasDPI()), adding empty bits to the data report …and so on.
To refactor this mess to ECS, it’s far easier, you just create a Component Button, a Component ScrollBall, and a Component LaserSensor; then you compose them as you wish under a mouse entity. The detailed-design can be anything ranging from simple generic objects added to a collection to more advanced bizarre features.
One bizarre feature I thought of is the system Modules, a module is just an interface that provides a colllection of Components, so back to the mouse example, I have a hope that
CircuitModules can play a role in reusability behavior; where a mouse circuit module is reusable in other entities without rebuilding the whole logic when in need to the mouse circuit for other bizarre reasons.
If you plan to be as generic as possible in your tool/game/API or whatever, the ecs architectural pattern will make it possible for maintenance and modifiability reasons.
There are a lot of ways to implement an ecs architecture, as Paul said, the end that this is only an architectural pattern, it cannot describe the detailed-design clearly. There are game engines that support ecs internally nowadays, but this doesn’t add that much, data is much flexible to compose than anything ever.
If you are keen to know more, you can read the thread [An ECS API], also I have a software specification catalogue for articular-es, it displays the problem in general, then the one specifc solutions from the articular-es perspective (but it inherits the solution from the architecture itself).