title: Is it good practice to return an IEnumerable<T> for a collection that implements INotifyCollectionChanged
body: <p>Writing another question for SO, I came to a pattern that I use very often and I never really reflected about. But now, I’m no longer sure if this is the right way:</p>
  
  <p>If I have collections that my WPF-controls will bind to, I returned almost always <code>IEnumerable&lt;SomeType&gt;</code>. However internally , this is in most cases an <code>ReadOnlyObservableCollection&lt;SomeType&gt;</code>. I never had a problem with this and all consuming controls always updated correctly, what is not astonishing because they check for the <code>INotifyCollectionChanged</code>-interface. </p>
  
  <p>But my question is now, if this is bad practice to declare in the signature only the <code>IEnumerable&lt;SomeType&gt;</code> but to return (and also depend on) something much more powerful (<code>INotifyCollectionChanged</code>).</p>
  
  <p><strong>Update:</strong></p>
  
  <p>I try to clarify:</p>
  
  <p>My main intention is to return an <code>IEnumerable&lt;SomeType&gt;</code>. But most of the time, the returned <code>IEnumerable&lt;SomeType&gt;</code> implements also <code>INotifyCollectionChanged</code> such as <code>ReadOnlyObservableCollection&lt;SomeType&gt;</code> does. The consuming controls bind accordingly (what my second intention is).</p>
  
  <p>Maybe I should have asked: Is there an interface that exactly contains IEnumerable and INotifyPropertyChanged. </p>