为什么不允许以下C＃代码：

public abstract class BaseClass
{
    public abstract int Bar { get;}
}

public class ConcreteClass : BaseClass
{
    public override int Bar
    {
        get { return 0; }
        set {}
    }
}

CS0546'ConcreteClass.Bar.set'：无法覆盖，因为'BaseClass.Bar'没有可覆盖的集合访问器

因为Baseclass的作者已明确声明Bar必须是一个只读属性。推导打破合同并使其可读写是没有意义的。

我在这一点上和Microsoft在一起。
假设我是一位新程序员，被告知要针对Baseclass派生进行编码。我写了一些假设不能写入Bar的东西（因为Baseclass明确声明它是一个get only属性）。现在，根据您的推导，我的代码可能会损坏。例如

public class BarProvider
{ BaseClass _source;
  Bar _currentBar;

  public void setSource(BaseClass b)
  {
    _source = b;
    _currentBar = b.Bar;
  }

  public Bar getBar()
  { return _currentBar;  }
}

由于不能按照BaseClass接口设置Bar，BarProvider认为缓存是一件安全的事-因为Bar不能修改。但是，如果在派生中可以设置set，则如果有人在外部修改_source对象的Bar属性，则此类可以提供陈旧的值。重点是“ 保持开放，避免做鬼sneak的事情并使人感到惊讶 ”

更新：Ilya Ryzhenkov问：“为什么接口不按照相同的规则运行？” 嗯..我想到这变得更加泥泞。
接口是一个合同，上面写着“期望实现具有名为Bar的读取属性”。就我个人而言，如果看到接口，则不太可能将其假定为只读。当我在接口上看到一个get-only属性时，我将其读取为“任何实现都会公开此属性Bar”……在它单击的基类上，因为“ Bar是只读属性”。当然，从技术上讲，您并没有违反合同。因此，您在某种意义上是正确的。.最后，我要说：“使误解变得尽可能困难”。

我认为主要原因是语法太明确，以至于无法以其他任何方式工作。这段代码：

public override int MyProperty { get { ... } set { ... } }

明确指出get和set都是覆盖。set基类中没有任何内容，因此编译器会抱怨。就像您无法覆盖基类中未定义的方法一样，您也无法覆盖setter。

您可能会说编译器应该猜测您的意图，并且仅将重写应用于可以重写的方法（在这种情况下，即吸气剂），但这违背了C＃设计原则之一-编译器不得猜测您的意图，因为在您不知情的情况下可能会猜错。

我认为以下语法可能会做得很好，但是正如Eric Lippert一直说的那样，即使要实现这样的次要功能，仍然要付出很大的努力...

public int MyProperty
{
    override get { ... }
    set { ... }
}

或者，对于自动实现的属性，

public int MyProperty { override get; set; }

我今天偶然发现了一个同样的问题，我认为有一个很正当的理由想要这个。

首先，我想争论一下，拥有仅获取属性并不一定会转换为只读。我将其解释为“可以从此接口/抽象获取此值”，这并不意味着该接口/抽象类的某些实现不需要用户/程序显式设置此值。抽象类用于实现部分所需功能的目的。我绝对没有理由说，继承的类不能在不违反任何合同的情况下添加setter。

以下是我今天需要的简化示例。我最终不得不在我的界面中添加一个setter来解决这个问题。添加设置器而不添加例如SetProp方法的原因是，接口的一个特定实现使用DataContract / DataMember进行Prop的序列化，如果我仅出于此目的添加另一个属性，则将不必要地变得复杂序列化。

interface ITest
{
    // Other stuff
    string Prop { get; }
}

// Implements other stuff
abstract class ATest : ITest
{
    abstract public string Prop { get; }
}

// This implementation of ITest needs the user to set the value of Prop
class BTest : ATest
{
    string foo = "BTest";
    public override string Prop
    {
        get { return foo; }
        set { foo = value; } // Not allowed. 'BTest.Prop.set': cannot override because 'ATest.Prop' does not have an overridable set accessor
    }
}

// This implementation of ITest generates the value for Prop itself
class CTest : ATest
{
    string foo = "CTest";
    public override string Prop
    {
        get { return foo; }
        // set; // Not needed
    }
}

我知道这只是一篇“我的2美分”的帖子，但是我对原始的发帖人感同身受，并试图合理地认为这对我来说是一件好事，特别是考虑到直接从继承人继承时没有相同的限制接口。

同样，关于使用new而不是override的提述在这里也不适用，它根本行不通，即使这样做也不会给您想要的结果，即接口所描述的虚拟getter。

这是可能的

文艺青年最爱的 - 你可以重写一个只能获得法与制定者，如果你想。基本上就是：

1. 创建一个new具有相同名称的a get和a 的属性set。

2. 如果您不执行其他任何操作，则在get通过其基类型调用派生类时，仍将调用旧方法。要解决此问题，请添加一个abstract用于override旧get方法的中间层，以强制其返回新get方法的结果。

这使我们能够使用get/ 覆盖属性，set即使它们在基本定义中缺少属性也是如此。

作为奖励，您还可以根据需要更改退货类型。

• 如果基本定义是get-only，则可以使用派生更多的返回类型。

• 如果基本定义是set-only，则可以使用派生较少的返回类型。

• 如果基本定义已经是get/ set，则：

  • 您可以使用更衍生的返回类型，如果你把它set-only;

  • 您可以使用衍生少返回类型，如果你把它get-only。

在所有情况下，都可以根据需要保留相同的返回类型。为了简单起见，以下示例使用相同的返回类型。

情况：既有get属性

您有一些无法修改的类结构。也许它只是一个类，或者它是一个预先存在的继承树。无论如何，您都想向set属性添加方法，但不能这样做。

public abstract class A                     // Pre-existing class; can't modify
{
    public abstract int X { get; }          // You want a setter, but can't add it.
}
public class B : A                          // Pre-existing class; can't modify
{
    public override int X { get { return 0; } }
}

问题：无法override在get-only与get/set

您想override使用get/ set属性，但无法编译。

public class C : B
{
    private int _x;
    public override int X
    {
        get { return _x; }
        set { _x = value; }   //  Won't compile
    }
}

解决方案：使用abstract中间层

虽然您不能直接override使用get/ set属性，但可以：

1. 创建一个具有相同名称的new get/ set属性。

2. override旧get方法与新get方法的访问者一起确保一致性。

因此，首先编写abstract中间层：

public abstract class C : B
{
    //  Seal off the old getter.  From now on, its only job
    //  is to alias the new getter in the base classes.
    public sealed override int X { get { return this.XGetter; }  }
    protected abstract int XGetter { get; }
}

然后，编写不会更早编译的类。这次将编译，因为您实际上不是override在使用get-only属性；相反，您将使用new关键字替换它。

public class D : C
{
    private int _x;
    public new virtual int X { get { return this._x; } set { this._x = value; } }

    //  Ensure base classes (A,B,C) use the new get method.
    protected sealed override int XGetter { get { return this.X; } }
}

结果：一切正常！

显然，这按预期工作D。

var test = new D();
Print(test.X);      // Prints "0", the default value of an int.

test.X = 7;
Print(test.X);      // Prints "7", as intended.

一切仍然有效-AS-目标观察时，D它的基类之一，例如A或B。但是，它起作用的原因可能不太明显。

var test = new D() as B;
//test.X = 7;       // This won't compile, because test looks like a B,
                    // and B still doesn't provide a visible setter.

但是，的基类定义get最终仍会被派生类的定义所覆盖get，因此它仍然是完全一致的。

var test = new D();
Print(test.X);      // Prints "0", the default value of an int.

var baseTest = test as A;
Print(test.X);      // Prints "7", as intended.

讨论区

此方法允许您将set方法添加到get-only属性。您还可以使用它来执行以下操作：

1. 将任何属性更改为get-only，set-only或get-and- set属性，而不管它在基类中是什么。

2. 更改派生类中方法的返回类型。

主要缺点是要做更多的编码，并且abstract class在继承树中增加了额外的代码。对于带有参数的构造函数，这可能会有些烦人，因为必须在中间层中复制/粘贴这些参数。

我同意不能覆盖派生类型中的getter是一种反模式。只读指定缺少实现，而不是纯功能的契约（由最高投票答案表示）。

我怀疑微软有这个局限性，可能是因为引起了同样的误解，或者可能是因为简化了语法。但是，现在可以将范围应用于单独获取或设置，也许我们可以希望重写也可以。

最高投票答案表明了一个误解，即只读属性应该比读/写属性更“纯”，这是荒谬的。只需看一下框架中许多常见的只读属性即可；该值不是常数/纯粹是函数性的；例如，DateTime.Now是只读的，但除纯函数值以外的任何值。尝试“缓存”只读属性的值（假设下次该属性将返回相同的值）是有风险的。

无论如何，我都使用以下策略之一来克服此限制；两者都不尽如人意，但会让您在这种语言缺陷之外li行：

   class BaseType
   {
      public virtual T LastRequest { get {...} }
   }

   class DerivedTypeStrategy1
   {
      /// get or set the value returned by the LastRequest property.
      public bool T LastRequestValue { get; set; }

      public override T LastRequest { get { return LastRequestValue; } }
   }

   class DerivedTypeStrategy2
   {
      /// set the value returned by the LastRequest property.
      public bool SetLastRequest( T value ) { this._x = value; }

      public override T LastRequest { get { return _x; } }

      private bool _x;
   }

您也许可以通过创建新属性来解决该问题：

public new int Bar 
{            
    get { return 0; }
    set {}        
}

int IBase.Bar { 
  get { return Bar; }
}

我可以理解您的所有观点，但实际上，在这种情况下，C＃3.0的自动属性变得毫无用处。

你不能做这样的事情：

public class ConcreteClass : BaseClass
{
    public override int Bar
    {
        get;
        private set;
    }
}

IMO，C＃不应限制这种情况。开发人员有责任相应地使用它。

问题在于，无论出于何种原因，Microsoft都决定应该有三种不同类型的属性：只读，只写和读写，在给定的上下文中只有给定的签名可以存在其中一种。属性只能由相同声明的属性覆盖。要执行您想要的操作，有必要创建两个具有相同名称和签名的属性-其中一个是只读的，而另一个是可读写的。

就个人而言，我希望可以取消“属性”的整个概念，除了可以将属性式语法用作调用“ get”和“ set”方法的语法糖外。这不仅可以方便使用“添加集”选项，还可以允许“获取”返回与“集”不同的类型。尽管这种能力不会经常使用，但是有时使“ get”方法返回包装对象，而“ set”可以接受包装数据或实际数据有时会很有用。

为了解决此问题，请使用以下解决方法：

var UpdatedGiftItem = // object value to update;

foreach (var proInfo in UpdatedGiftItem.GetType().GetProperties())
{
    var updatedValue = proInfo.GetValue(UpdatedGiftItem, null);
    var targetpropInfo = this.GiftItem.GetType().GetProperty(proInfo.Name);
    targetpropInfo.SetValue(this.GiftItem, updatedValue,null);
}

这样，我们可以在只读属性上设置对象值。可能无法在所有情况下都起作用！

您应该更改问题标题，以详细说明问题仅是有关覆盖抽象属性的问题，或者是有关问题一般是覆盖类的get-only属性的问题。

如果是前者（覆盖抽象属性）

该代码是无用的。仅基类不能告诉您被迫重写Get-Only属性（也许是接口）。基类提供了通用功能，这些功能可能需要实现类的特定输入。因此，通用功能可能会调用抽象属性或方法。在给定的情况下，常见的功能性方法应要求您重写一个抽象方法，例如：

public int GetBar(){}

但是，如果您对此没有控制权，并且基类的功能从其自己的公共属性（怪异）中读取，则只需执行以下操作：

public abstract class BaseClass
{
    public abstract int Bar { get; }
}

public class ConcreteClass : BaseClass
{
    private int _bar;
    public override int Bar
    {
        get { return _bar; }
    }
    public void SetBar(int value)
    {
        _bar = value;
    }
}

我想指出（怪异的）评论：我要说的一种最佳实践是，一个类不使用其自己的公共属性，而在它们存在时使用其私有/受保护的字段。所以这是一个更好的模式：

public abstract class BaseClass {
    protected int _bar;
    public int Bar { get { return _bar; } }
    protected void DoBaseStuff()
    {
        SetBar();
        //Do something with _bar;
    }
    protected abstract void SetBar();
}

public class ConcreteClass : BaseClass {
    protected override void SetBar() { _bar = 5; }
}

如果是后者（覆盖类的get-only属性）

每个非抽象属性都有一个setter。否则，它是无用的，您不应该在意它。Microsoft不必允许您做您想做的事。原因是：安装员以某种形式存在，并且您可以轻松地实现想要的Veerryy。

基类，或者你可以读取与属性的任何类{get;}，有一些类型的暴露二传手该属性的。元数据将如下所示：

public abstract class BaseClass
{
    public int Bar { get; }
}

但是实现将具有复杂性范围的两个方面：

最少复杂度：

public abstract class BaseClass
{
    private int _bar;
    public int Bar { 
        get{
            return _bar;
        }}
    public void SetBar(int value) { _bar = value; }
}

最复杂：

public abstract class BaseClass
{
    private int _foo;
    private int _baz;
    private int _wtf;
    private int _kthx;
    private int _lawl;

    public int Bar
    {
        get { return _foo * _baz + _kthx; }
    }
    public bool TryDoSomethingBaz(MyEnum whatever, int input)
    {
        switch (whatever)
        {
            case MyEnum.lol:
                _baz = _lawl + input;
                return true;
            case MyEnum.wtf:
                _baz = _wtf * input;
                break;
        }
        return false;
    }
    public void TryBlowThingsUp(DateTime when)
    {
        //Some Crazy Madeup Code
        _kthx = DaysSinceEaster(when);
    }
    public int DaysSinceEaster(DateTime when)
    {
        return 2; //<-- calculations
    }
}
public enum MyEnum
{
    lol,
    wtf,
}

我的意思是，无论哪种方式，您都会看到塞特犬。在您的情况下，您可能想要覆盖，int Bar因为您不希望基类处理它，无权查看它的处理方式，或者被责成违背您的意愿快速地编写一些代码。

无论是前者还是后者（结论）

长篇短篇：Microsoft无需更改任何内容。您可以选择如何设置实现类，以及在没有构造函数的情况下使用全部或全部不使用基类。

解决方案仅适用于一小部分用例，但是：在C＃6.0中，将自动为覆盖的仅吸气剂属性添加“只读”设置器。

public abstract class BaseClass
{
    public abstract int Bar { get; }
}

public class ConcreteClass : BaseClass
{
    public override int Bar { get; }

    public ConcreteClass(int bar)
    {
        Bar = bar;
    }
}

因为那样会破坏封装和实现隐藏的概念。请考虑以下情况：创建类并交付它，然后类的使用者使自己能够设置最初仅为其提供吸气剂的属性。它会有效地破坏您可以在实现中依赖的类的所有不变量。

这并非不可能。您只需要在媒体资源中使用“ new”关键字即可。例如，

namespace {
    public class Base {
        private int _baseProperty = 0;

        public virtual int BaseProperty {
            get {
                return _baseProperty;
            }
        }

    }

    public class Test : Base {
        private int _testBaseProperty = 5;

        public new int BaseProperty {
            get {
                return _testBaseProperty;
            }
            set {
                _testBaseProperty = value;
            }
        }
    }
}

看来这种方法满足了讨论的双方。使用“ new”会破坏基类实现和子类实现之间的契约。当一个类可以具有多个合同（通过接口或基类）时，这是必需的。

希望这可以帮助

基类中的只读属性指示该属性表示始终可以从类内部确定的值（例如，与对象的（db-）上下文匹配的枚举值）。因此，确定值的责任在于类中。

添加设置器将在此处引起一个尴尬的问题：如果将值设置为除已存在的单个可能值以外的任何值，都将发生验证错误。

但是，规则通常会有例外。例如，很可能在一个派生类中，上下文将可能的枚举值缩小到十分之三（十分之三），但是此对象的用户仍然需要确定哪个是正确的。派生类需要将确定值的责任委托给此对象的用户。 重要的是要认识到该对象的用户应充分了解此异常，并承担设置正确值的责任。

在这种情况下，我的解决方案是将属性保留为只读，并向派生类添加新的读写属性以支持异常。覆盖原始属性将仅返回新属性的值。新属性可以具有适当的名称，以正确指示此异常的上下文。

这也支持了有效的说法：Gishu提出的“使误解越发严重”。

因为在IL级别，读/写属性转换为两个方法（getter和setter）。

覆盖时，您必须继续支持基础接口。如果您可以添加一个setter，那么您将有效地添加一个新方法，就类的接口而言，该方法对于外界仍然是不可见的。

的确，添加新方法本身并不会破坏兼容性，但是由于它将保持隐藏状态，因此决定禁止这样做是完全合理的。

因为具有只读属性（没有设置器）的类可能有充分的理由。例如，可能没有任何基础数据存储。允许您创建二传手会破坏班级制定的合同。糟糕的OOP。