Сделать свойство readonly в производном классе

Question

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

Каков наилучший способ для этого? Должен ли я просто выбросить InvalidOperationException в set { }?

Answer 1

Наличие сеттера в InvalidOperationException в производном классе нарушает Liskov Subsitution Principle. По сути делает использование сеттера контекстуальным для типа базового класса, что существенно исключает значение полиморфизма.

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

Один из способов обойти это - немного разбить иерархию.

class C1 { 
    public virtual int ReadOnlyProperty { get; } 
} 
class C2 { 
    public sealed override int ReadOnlyProperty { 
    get { return Property; } 
    } 
    public int Property { 
    get { ... } 
    set { ... } 
    } 
} 

Ваш тип у вас возникли проблемы с C1 могли наследовать в этом сценарии, а остальные могли бы перейти на проистекают из C2

Answer 2

можно скрыть оригинальную реализацию и вернуть базовую реализацию:

class Foo 
{ 
    private string _someString; 
    public virtual string SomeString 
    { 
     get { return _someString; } 
     set { _someString = value; } 
    } 
} 

class Bar : Foo 
{ 
    public new string SomeString 
    { 
     get { return base.SomeString; } 
     private set { base.SomeString = value; } 
    } 
} 

namespace ConsoleApplication3 
{ 
    class Program 
    { 
     static void Main(string[] args) 
     { 
      Foo f = new Foo(); 
      f.SomeString = "whatever"; // works 
      Bar b = new Bar(); 
      b.SomeString = "Whatever"; // error 
     } 
    } 
} 

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

Answer 3

Вам не разрешено скрывать общедоступные члены базового класса на C#, потому что кто-то может взять экземпляр вашего производного класса, передать его в ссылку на базовый класс и получить доступ к этому свойству.

Если вы хотите создать класс, который предоставляет большинство, но не всех, интерфейса другого класса, вам придется использовать агрегацию. Не наследуйте от «базового класса», просто включите один в «производный» по значению и предоставите свои собственные функции-члены для частей функциональности «базового класса», которые вы хотите открыть. Эти функции затем могут просто перенаправлять вызовы на соответствующие функции «базового класса».

Answer 4

Просто определите свойство с новым ключевым словом и не предоставите метод Setter в производном классе. Это также скроет свойство базового класса, однако, как упоминалось в mjfgates, вы все равно можете получить доступ к свойству базового класса, назначив его экземпляру базового класса. Это полиморфизм.

Answer 5

Есть случаи, когда шаблон, который вы описываете, оправдан. Например, может быть полезно иметь абстрактный класс MaybeMutableFoo, из которого производные подтипы MutableFoo и ImmutableFoo. Все три класса включают имущество IsMutable и методы AsMutable(), AsNewMutable() и AsImmutable().

В этой ситуации было бы полностью правильным, чтобы MaybeMutableFoo обнаружил свойство чтения-записи, если его контракт явно указывает, что установщик может не работать, если IsMutable не возвращает true. Объект, который имеет поле типа MaybeMutableFoo, которое имеет место с экземпляром ImmutableFoo, может быть совершенно доволен этим экземпляром, если до или после него он не должен был писать на него, после чего он заменил бы поле объектом, возвращаемым через AsMutable(), а затем использовал его как измененный foo (он знал бы, что он изменен, поскольку он только что заменил его).При наличии MaybeMutableFoo включите сеттер, чтобы избежать необходимости делать какие-либо будущие придания типов в поле, как только оно было сделано для обращения к изменяемому экземпляру.

Лучший способ разрешить такой шаблон - избежать реализации виртуальных или абстрактных свойств, а вместо этого реализовать не виртуальные свойства, чьи геттеры и сеттеры привязаны к виртуальным или абстрактным методам. Если один имеет базовый класс

public class MaybeMutableFoo 
{ 
    public string Foo {get {return Foo_get();} set {Foo_set(value);} 
    protected abstract string Foo_get(); 
    protected abstract void Foo_set(string value}; 
} 

то производный класс ImmutableFoo может объявить:

new public string Foo {get {return Foo_get();} 

сделать его Foo свойство только для чтения, не мешая с возможностью кодировать переопределения для абстрактного Foo_get() и Foo_set() методов. Обратите внимание, что замена только для чтения Foo не изменяет поведение свойства get; цепочки версий, доступные только для чтения, для того же метода базового класса, что и свойство базового класса. Выполнение этого способа гарантирует, что есть одна точка патча для изменения свойства getter и одна для изменения сеттера, и эти точки патча не будут меняться, даже если само свойство будет переопределено.

Answer 6

Я думаю, что я такая ситуация лучшее решением является новым ключевым словом

public class Aclass {   
    public int ReadOnly { get; set; } 
} 

public class Bclass : Aclass {   
    public new int ReadOnly { get; private set; } 
}