Is an interface with two collection properties, where the second filters the first collection, idiomatic for C#?

Question

I had an interesting discussion with a coworker that revolved around how people interpret the use of properties and methods on an interface. For example, let's say we have a blog with posts in various statuses: Working and Published.

When in "Working" the author is still making changes and shouldn't be visible to readers. When "Published", well... it's published and end users can read it.

Let's also say we have an interface for the Blog, which I defined as:

public interface IBlog
{
    IEnumerable<Post> Posts { get; }
    IEnumerable<Post> PublishedPosts { get; }
}

My coworker was worried that users of this interface might interpret these two properties as separate collections of objects. I figured since you have a "Posts" property, and another property called "Published Posts" that returns the same kind of object that people would make the correct assumption that Posts is one collection, and PublishedPosts is a filtered view of the Posts collection.

His suggestion was:

public interface IBlog
{
    IEnumerable<Post> Posts { get; }
    IEnumerable<Post> GetPublishedPosts();
}

Basically, replace the PublishedPosts property with a GetPublishPosts() method. He said this was more idiomatic for C#, because a method communicates to people using the interface that you are performing an operation on the "Posts" collection (filtering it by status). I haven't really seen any formal documentation for this, but that doesn't stop the C# community from leaning one direction or the other.

Is having one collection property, and then methods to filter the collection, or having two collections where the second filters the first idiomatic for C#? If so, is there formal documentation anywhere?

Answer 1

IEnumerable<Post> PublishedPosts { get { return Posts.Where(p => p.Published) }; }

if you want a single place for your filtering logic. Or, simply filter as needed:

var publishedPosts = myBlog.Posts.Where(p => p.Published);

The second version doesn't require you to go to the property definition to determine what it does. Don't make the users of your class guess; if the naming (which is what this is really all about) doesn't make things clear, then use better property names, provide adequate comments or let them see the source code.

I don't recommend the use of a method here. Methods imply processing and a return delay (i.e. more than 50ms), and there isn't any processing taking place here beyond the use of the filtering function. A method also implies that you're making copies of the original blog posts rather than returning a collection of references, which is probably not what you want.

I personally prefer the ad-hoc filter, because it allows you to work with a single, unambiguous property containing your blog post collection. A common place for your filtering logic is not really needed unless you plan on overhauling your architecture in the future, and if you really need that, hand your filter a higher-order function:

Func<Post, bool> published = p => p.Published; // one place to change filter logic
var publishedPosts = myBlog.Posts.Where(published);

Guidance from Microsoft:

Do use a method, rather than a property, in the following situations:

• The operation is orders of magnitude slower than a field set would be.
• The operation is a conversion, such as the Object.ToString method.
• The operation returns a different result each time it is called, even if the parameters do not change. For example, the Guid.NewGuid method returns a different value each time it is called. 8 The operation has a significant and observable side effect.
• The operation returns a copy of an internal state.
• The operation returns an array.

Use a method where the operation returns an array because to preserve the internal array, you would have to return a deep copy of the array, not a reference to the array used by the property. This fact, combined with the fact that developers use properties as though they were fields, can lead to very inefficient code.

Answer 2

If we look at the .NET CLR we can see some examples of sets and subsets exposed by the same object. For example, consider the following commonly-used collections from System.Web:

HttpRequest.Item - Returns all tag/value pairs in the request

HttpRequest.Form.Item - Returns only those tag/value pairs found in the body

HttpRequest.QueryString.Item - Returns only those tag/value pairs found in the querystring

The second and third collections are subsets of the first collection above, so they have the same set/subset relationship as the blog posts in the question posed by the OP.

Based on this example I might suggest the following:

interface IBlog : IEnumerable<Post>
{
    IEnumerable<Post> PublishedPosts { get;}
}

Answer 3

To me IEnumerable<Post> GetPublishedPosts(); no more infers a filter than IEnumerable<Post> PublishedPosts { get; }

public interface IBlog
{
    IEnumerable<Post> Posts { get; }
    IEnumerable<Post> GetPublishedPosts();
} 

By definition an interface does not define or restrict an implementation
There is nothing stopping the following implementation

public class Post
{ }
public interface IBlog
{
    IEnumerable<Post> Posts { get; }
    IEnumerable<Post> GetPublishedPosts();
}
public class Blog : IBlog
{
    private List<Post> posts = new List<Post>();
    private List<Post> postsPublished = new List<Post>();
    IEnumerable<Post> IBlog.Posts { get { return posts; } }
    IEnumerable<Post> IBlog.GetPublishedPosts() { return postsPublished; }
}