title: Referencing the same object in several collections by interface
body: <p><strong>Warning: this question uses an analogy to RPG as an example.</strong></p>
  
  <p>Let's say I'm making this RPG I've been dreaming of, using C#.
  When the player enters battle, there is some kind of battlefield appearing, that holds references to every elements relevant to the battle, like the various opponents and items available on the battlefield.</p>
  
  <p>Now all those elements have one but several roles:
  for instance, an Ally (which is a Fighter through direct inheritance) is able to move on the battlefield, to issue commands or to be targeted by ennemies.</p>
  
  <p>Now that mighty sword in the stone has also a few roles in battle. Obviously it can't move nor issue commands, but it can still be targeted, and it can (hopefully) be lifted or used.</p>
  
  <p>All these behaviors are represented by interfaces in my code, so that all objects with the same behaviors can be used regardless of the object that implements it.</p>
  
  <p>Code example:</p>
  
  <pre><code>public class Ally : Fighter, IMovable, IActor, ITarget
  {
      // IMovable implementation
      public void Move(...) { ... }
  
      // IActor implementation
      public bool HasInitiative { get { ... } }
  
      public ICommand IssueCommand(...) { ... }
  
      // ITarget implementation
      public void OnTarget(...) { ... }
  
      // other code ...
  }
  
  public class MightySword : ITarget, ILiftable, IUsable
  {
      // ITarget implementation
      public void OnTarget(...) { ... }
  
      // ... other interface implementation
  
      // other code ...
  }
  </code></pre>
  
  <p>Now my question is the following:
  How should my Battlefield class holds its references to all these objects?
  I came up with two possible solutions, but at this point it's not clear which one is the best, and whether better solutions are to be found.</p>
  
  <p><strong>Solution A:</strong></p>
  
  <p>Reference several time, access directly:
  Using this solution, each object is referenced once per interface it implements, so my battlefield class would look like below:</p>
  
  <pre><code>public class Battlefield : ...
  {
     IList&lt;IMovable&gt; movables;
     IList&lt;ITarget&gt; targets;
     IList&lt;IActor&gt; actors;
     // ... and so on
  }
  </code></pre>
  
  <p>and the Battlefield.Update method could look this way:</p>
  
  <pre><code>Update(...) 
  {
    // Say every actor needs to target somebody else
    // it has nothing to do in the Update method,
    // but this is an example
    foreach (IActor actor in actors) 
    {
      if (actor.HasInitiative) 
      {
        ITarget target = targets[actor.TargetIndex];
        target.OnTarget(actor.IssueCommand(...));
      }
    }
  }
  </code></pre>
  
  <p>This solution allows us to have a direct access to the objects' various behavior, but it introduces redundancy, as an Ally would have to be referenced into movables, targets and actors
  .
  This redundancy means a bigger memory footprint and will make adding and removing an object to the battlefield a lot more complicated (each type should now from which collections it has to be added/removed).</p>
  
  <p>Also, adding a new interface means adding a new collection to hold the item and manage the corresponding code.</p>
  
  <p><strong>Solution B:</strong></p>
  
  <p>Reference once, filter access:
  Using this solution, all objects derive from a single class or interface (something akin to IBattleElement), and are stored in one single collection.
  When using the elements, they are filtered according to their types:</p>
  
  <pre><code>Update(...)
  {
      IList&lt;IActor&gt; actors = elements.OfType&lt;Actor&gt;();
      foreach (IActor actor in actors) 
      {
       ITarget target = elements.OfType&lt;Target&gt;()[actor.TargetIndex];
       target.OnTarget(actor.IssueCommand(...));
      }
  }
  </code></pre>
  
  <p>There. No more redundancy, but I dislike using a "typeof" construct and I generally try to avoid it. Obviously this is worse regarding runtime performance.</p>
  
  <p>I implemented solution A in my toy project, but there is nothing performance critical in this project.
  The answer should consider not only performance (both memory wise and CPU wise), but also what offers the best design for the operations me or my designers might have to perform, such as adding new classes of BattleElement or new interfaces for new behaviors, adding and removing instances of objects from a Battlefield, and more generally use them in the game logic.</p>
  
  <p>I apologize for the general silliness of my examples, I hope my English is good enough, and that my question carries at least a little bit of interest and doesn't indicate an overall silliness in the design itself.</p>