Behaviour abstraction

Note, to make this article more readable, I will use the words entity view in place of EntitViewStructs and EntityStructs.

With ECS in general behaviors are specialized through the specialization of entity data (as opposite of specialization of objects like it happens in OOP). In order to write modular engines, it's necessary to separate the generic behaviors from the specialized ones. Entities could generate modular entity views for generic behaviours and specialized entity views for specialize behaviours, so that you could have:

GenericBehaviourEngine -> GenericEntityView. Generic engines can use only generic entity views, like a HealthEngine would use only modular health entity views from all the entities that have health.

SpecializedBehaviourEngine -> SpecializedEntityView, GenericEntityView. Specialized engines can use Specialized entity views AND generic entity views. A specialized engine can add the behavior for specific entities to react or modify the health in a specialized way while still using the generic health entity view.

the Liskov Principle is applied in ECS through data abstraction and not class abstraction. A generic Engine must be able to see a specialized Entity through generic entity views without needing to access data of specialize entity views. A specialized engine must be able to use either the specialized data and the generic one. Instead to achieve this with inheritance, it's achieved adding Entity Views. The LSP is applied in this sense: A generic engine can operate on specialized entities through the use of generic entity views.

The LSP is all about modularity. It's about writing generic engines that can add shared behaviors through different set of specialized entities

More on this from my article: http://www.sebaslab.com/the-quest-for-maintainable-code-and-the-path-to-ecs/