Свойство C# типа IEnumerable

Question

У меня есть класс полезности ContainerQuery, который состоит из нуля или более ContainerQueryClause объектов. После того как пользователь подготовил запрос (т.е. добавлены некоторые положения), интерфейс для моей структуры необходимо получить объект, который поддерживает:

interface IContainerQuery 
{ 
    public IEnumerable<ContainerQueryClause> Clauses { get; } 
} 

Что лучшей реализацией для IContainerQuery и почему?

Вариант А)

class ContainerQuery 
{ 
    public IEnumerable<ContainerQueryClause> Clauses { get; set; } 
} 

Вариант б)

class ContainerQuery 
{ 
    public ContainerQuery() 
    { 
     Clauses = new List<ContainerQueryClause>(); 
    } 

    public ICollection<ContainerQueryClause> Clauses { get; private set; } 
} 

Вариант C)

class ContainerQuery 
{ 
    public ContainerQuery(IEnumerable<ContainerQueryClause> clauses) 
    { 
     Clauses = clauses; 
    } 

    public IEnumerable<ContainerQueryClause> Clauses { get; private set; } 
} 

Вариант д)

Сочетание вышеуказанных подходов или полностью другой подход.

Примечание стороны 1: хотя ContainerQuery в настоящее время выглядит как «это перечислимые дизъюнкты» Я хочу, чтобы смоделировать это ради будущего, как «имеет Перечислимый из положений».

Вопрос: Есть ли вообще лучший рисунок или рисунок для создания свойств типа IEnumerable<T>? Если нет, какой подход подходит для ситуаций?

Бокового вопрос: ли вы создать интерфейс IContainerQuery, чтобы ваша внутренняя структура использовать непреложную версию или только вы воздержитесь от этого, как «вашего внутреннего кода не настолько глуп, чтобы изменить запрос позже»?

---

Дополнительный контекст: пользователь создает новый запрос контейнера и хочет добавить некоторые предложения. Там нет фанки беглый интерфейс или что-то вроде этого. После передачи готового запроса в мою фреймворк, моя инфраструктура хочет только читать все предложения и не имеет права вносить в нее какие-либо изменения (для описания интерфейса).

Answer 1

Начните со следующей реализации. Зачем? Он предоставляет минимальные знания и возможности для вызывающего абонента.

• вы можете использовать класс с конструктором по умолчанию => не думать нужно о том, что происходит с параметром
• Морозы не всегда инициализируются => нет необходимости проверять нуль
• Морозов не IEnumerable => минимальный набор функциональных возможностей, максимальная гибкость для внутреннего представления

Если вы можете жить с реализацией, все готово. Если вы считаете, что ContainerQuery без предложения не имеет смысла, добавьте его в конструктор, чтобы вызывающий вызывал значение. Если вы предлагаете, чтобы вызывающий вызывал некоторые методы из ICollection (добавление/удаление после построения ContainerQuery), чем использование этого интерфейса. И так далее ...

public class ContainerQuery : IContainerQuery 
{ 
    public ContainerQuery() 
    { 
    Clauses = new List<ContainerQueryClause>(); 
    } 

    public IEnumerable<ContainerQueryClause> Clauses { get; private set; } 
}