title: Does implementing IDisposable contradict composition aggregation?
body: <p>In UMLs <a href="https://www.uml-diagrams.org/composition.html" rel="nofollow noreferrer">composition</a> aggregations I tend to use the <code>IDisposable</code> interface/pattern to force the <em>"<code>Child</code> can't exist without <code>Parent</code>"</em> - requirement the composition demands:</p>
  
  <pre class="lang-cs prettyprint-override"><code>public class Parent : IDisposable
  {
      private readonly _childs;
      public IReadOnlyCollection&lt;Child&gt; Childs =&gt; _childs;
  
      public Parent()
      {
          _childs = new List&lt;Child&gt;();
      }
  
      public Child CreateChild()
      {
          var child = new Child();
          _childs.Add(child);
          return child;
      }
  
      public void Dispose()
      {
          foreach (var child in _childs)
              child.Dispose();
      }
  }
  
  public class Child : IDisposable
  {
      internal Child() {}
  
      public void Dispose()
      {
           //Cleanup object, imagine an idempotent implementation
      }
  }
  </code></pre>
  
  <p>So far, so good. But now imagine this piece of code:</p>
  
  <pre class="lang-cs prettyprint-override"><code>var parent = new Parent();
  var child = parent.CreateChild();
  child.Dispose();
  //At this point parent.Childs contains a disposed child object
  </code></pre>
  
  <p>Since I am currently facing such a situation in a library I develop, several questions come to my mind:</p>
  
  <ul>
  <li>Is it okay, that <code>parent.Childs</code> contains an (in practise) unusable object?
  
  <ul>
  <li>If yes
  
  <ul>
  <li>would you ignore it, since it's the users own decision to prematurely dispose it?</li>
  </ul></li>
  <li>If not
  
  <ul>
  <li>Is there some kind of best-practise on how to deal with premature disposal of child-objects in C#? My first thought was the use of a callback function/delegate on disposal of the child object to remove itself from the list of active instances, but to me that sounds rather clumsy.</li>
  <li>Is there another excuse so that I can wash my hands of responsibility?</li>
  </ul></li>
  </ul></li>
  </ul>
  
  <p>From an architectural point of view the main problem is, that <code>IDisposable</code> is visible to everyone being able to obtain an instance of <code>Child</code>. Hiding it basically means making use of OO-polymorphy and extract the ability of disposal to an invisible implementation. But for many classes in a domain model this gets an absolutely bloating factor with no additional benefit. Furthermore it inherently interprets UMLs composition aggregation as <em>"<code>Child</code> can <strong>only</strong> be destroyed by <code>Parent</code>"</em>, which is incorrect in my opinion:</p>
  
  <pre class="lang-cs prettyprint-override"><code>public interface IChild
  {
      //Child methods
  }
  
  internal class Child : IChild, IDisposable
  {
      //See implementation above
  }
  
  public class Parent : IDisposable
  {
      public IReadOnlyCollection&lt;IChild&gt; Childs =&gt; _childs;
  
      public IChild CreateChild()
      {
          var child = new Child();
          _childs.Add(child);
          return child;
      }
  }
  </code></pre>