Merge pull request #303 from stride3d/Eideren-patch-1

Update flexible-processing.md

en/manual/engine/entity-component-system/flexible-processing.md

@@ -37,7 +37,7 @@ The main difference compared to [`EntityProcessor`](xref:Stride.Engine.EntityPro
 is that [`IComponent`](xref:Stride.Engine.FlexibleProcessing.IComponent`2) is not limited to concrete types, your processor may operate on interfaces as well;
 ```cs
 // Here, declaring the interface, which will be the type received by the processor
-public interface IInteractable : IComponent<IInteractable.ShapeProcessor, IInteractable>
+public interface IInteractable : IComponent<IInteractable.InteractableProcessor, IInteractable>
 {
     void Interact();
     public class InteractableProcessor : IProcessor
@@ -47,7 +47,7 @@ public interface IInteractable : IComponent<IInteractable.ShapeProcessor, IInter
     }
 }
 
-// Now any component implementing IInteractable will be processed by the ShapeProcessor
+// Now any component implementing IInteractable will be processed by the InteractableProcessor
 public class Button : StartupScript, IInteractable
 {
     public void Interact(){}
@@ -91,4 +91,4 @@ public interface ISpecialTick : IComponent<ISpecialTick.Processor, ISpecialTick>
 
 ## Performance
 While it is more flexible, processing components as interfaces instead of concrete class may introduce some overhead.
-If the system you're writing is performance critical you should look into strategies to elide or reduce virtual calls in your hot path.
+If the system you're writing is performance critical you should look into strategies to elide or reduce virtual calls in your hot path.