È un'interfaccia con due proprietà di raccolta, in cui la seconda filtra la prima raccolta, idiomatica per C #?

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

se vuoi un posto unico per la tua logica di filtraggio. Oppure, semplicemente filtrare secondo necessità:

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

La seconda versione non richiede di andare alla definizione della proprietà per determinare cosa fa. Non indovinare gli utenti della tua classe; se la denominazione (che è ciò che è veramente tutto) non chiarisce le cose, quindi usa nomi di proprietà migliori, fornisci commenti adeguati o lascia che vedano il codice sorgente.

Non consiglio l'uso di un metodo qui. I metodi implicano l'elaborazione e un ritardo di ritorno (cioè più di 50 ms), e non vi è alcuna elaborazione che avvenga qui oltre l'uso di la funzione di filtro. Un metodo implica anche che stai facendo delle copie dei post originali del blog piuttosto che restituire una raccolta di riferimenti, che probabilmente non è ciò che desideri.

Personalmente preferisco il filtro ad-hoc, perché ti consente di lavorare con una singola proprietà non ambigua contenente la raccolta di post del blog. Un luogo comune per la tua logica di filtraggio non è realmente necessario a meno che non pianifichi di revisionare la tua architettura in futuro e, se davvero ne hai bisogno, passa al filtro una funzione di ordine superiore:

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

Guida di 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.

Se guardiamo a .NET CLR possiamo vedere alcuni esempi di insiemi e sottoinsiemi esposti dallo stesso oggetto. Ad esempio, considera le seguenti raccolte di uso comune da System.Web :

HttpRequest.Item - Restituisce tutte le coppie tag / valore nella richiesta

HttpRequest.Form.Item - Restituisce solo le coppie tag / valore rilevate nel corpo

HttpRequest.QueryString.Item - Restituisce solo le coppie tag / valore trovate nella querystring

La seconda e la terza collezione sono sottoinsiemi della prima raccolta di cui sopra, quindi hanno la stessa relazione set / sottoinsieme dei post del blog nella domanda posta dall'OP.

In base a questo esempio, potrei suggerire quanto segue:

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

Per me IEnumerable<Post> GetPublishedPosts(); non viene più un filtro di IEnumerable<Post> PublishedPosts { get; }

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

Per definizione un'interfaccia non definisce o limita un'implementazione
Non c'è nulla che fermi la seguente implementazione

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; }
}