Добавляющие свойства к интерфейсу предотвращают создающий частный/защищенный “набор” в производных типах?

Править: Оказывается, что я пропустил что-то очевидное, но я собираюсь оставить вопрос открытым в случае, если кто-то еще делает ту же очевидную ошибку. Благодаря тем, кто указал, это Видит нижнюю часть для объяснения.

Действительно ли возможно иметь непубличный набор на свойстве, которое переопределяет интерфейсное свойство?

Возможно, у меня есть глупый момент, но мне кажется, что определение свойства в интерфейсе implicily требует, чтобы никакой класс получения не мог обеспечить непубличный набор для упомянутого свойства.

Пример:

interface IField
{
    bool IsValid { get; }
}

... и так как интерфейсные свойства не могут иметь средств модификаторов доступа что:

class Field : IField
{
    public override bool IsValid { get; protected set; }
}

... не будет возможно несмотря на то, что это отвечает интерфейсным требованиям концептуально.

IMO это имеет большие отрицательные последствия для инкапсуляции, которая могла бы быть сделана через непубличные Свойства, и предотвращает много скороговорок общего использования для Propertes.

Я знаю, что можно создать непубличного члена SetIsValid, который изменяет общее запоминающее устройство, но это создало бы непоследовательный шаблон и добавило бы, что иначе будет шумом кода, было это не необходимый.

Я пропустил что-то?

Править: Да я пропустил что-то

Я изменяю чужой код в данный момент и просто понимаю, что класс боролся с реализованным интерфейс и полученный из базового класса. И я плохо знаком с c#, Это - то, что вызвало беспорядок переопределения.

фактический класс был похож:

class Field : IField, BaseField
{
    public override bool IsValid { get; protected set; }
}

... где BaseField реализовал интерфейс также, но не реализовал набор.