Why Implementors?

Implementors are a unique feature of Svelto.ECS and they are useful in a semi-ECS environment. in Svelto.ECS an Entity can generate EntityViewStructs and EntityStructs: the latter is a pure struct with pure data and as such is allocation 0 and cache friendly, the former is a struct of interfaces that are implemented through the "implementors" objects (you are responsible of allocating the implementors).

The implementors are used to hide underling OOP platform specifics and act as a bridge between OOP objects and Svelto.ECS entities. An implementor, which for example can be a Monobehaviour or a BehaviourTree Node of an external BT library, hides all the dependencies that come from the platform.

Beside some rare exceptions or the use of other external libraries, Implementors are always Monobehaviours in Unity. All the Unity functionalities that come from the MonoBehaviours are known to the Svelto.ECS engines through the EntityViewStruct interfaces.

In the BT example, The Engine will see the BehaviourTree node as an ECS compliant interface, but at the same time the Node is the actually node of the BT library. In this way the engine will never know about the library and at the same time it will communicate to the library through the implementor. The implementors implements the entity components interface, which means they must hold their data. The implementor must see the BT library as a blackbox and you still will need to write the logic that the BT needs inside the engine. However the engine will just set values that the implementor will redirect to the library through the node. At the same time the node/implementor can listen to the library events, which will be redirected to the Engine.

In this sense the implementor works as a View and the Engine as Presenter of the MVP pattern.

The only exception to the rule that Implementors are used to map existing OOP libraries, is the case when you need to share the same data memory between entities. In this case the implementor will be a normal object and can be used to build multiple entities. The Entities will be able to access to the same data in memory through the implementor reference.

Implementors are not the only one day to deal with OOD objects, alterantives exists to avoid using EntityViewStructs at all, but these are more advanced cases that I will cover later.