blocks|key|3157474|text|因为在IL级别，一个读/写属性转换为两个(getter和setter)方法。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157475|当覆盖时，你必须保持对底层接口的支持。如果您可以添加一个setter，那么您将有效地添加一个新方法，就您的类的接口而言，该方法对外部世界是不可见的。|3157476|诚然，添加一个新方法本身并不会破坏兼容性，但由于它仍然是隐藏的，所以决定不允许这样做是非常有意义的。|3157477|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Because at the IL level, a read/write property translates into two (getter and setter) methods.

When overriding, you have to keep supporting the underlying interface. If you could add a setter, you would effectively be adding a new method, which would remain invisible to the outside world, as far as your classes' interface was concerned.

True, adding a new method would not be breaking compatibility per se, but since it would remain hidden, decision to disallow this makes perfect sense.

blocks|key|3370465|text|因为这会打破封装和实现隐藏的概念。请考虑这样一种情况:当您创建一个类，将其发布，然后您的类的使用者使自己能够设置一个属性，而您最初只为该属性提供了一个getter。它将有效地打乱你的类的任何不变量，你可以在你的实现中依赖它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370466|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because that would break the concept of encapsulation and implementation hiding. Consider the case when you create a class, ship it, and then the consumer of your class makes himself able to set a property for which you originally provide a getter only. It would effectively disrupt any invariants of your class which you can depend on in your implementation.

blocks|key|367813|text|因为Baseclass的编写者已经显式声明Bar必须是只读属性。对于派生来说，打破这个契约并使其成为可读写是没有意义的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|367814|在这个问题上，我和微软站在一起。|367815|假设我是一个新的程序员，他被告知要针对Baseclass派生进行编码。我写了一些东西，假设Bar不能被写入(因为基类显式地声明它是一个get+only属性)。现在，使用您的派生，我的代码可能会崩溃。例如：|367816|public+class+BarProvider
{+BaseClass+_source;
++Bar+_currentBar;

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

++public+Bar+getBar()
++{+return+_currentBar;++}
}|code-block|syntax|javascript|367817|由于不能按照BaseClass接口设置栏，因此BarProvider假定缓存是安全的-因为栏不能被修改。但是，如果在派生中可以设置，那么如果有人在外部修改了_source对象的Bar属性，这个类可能会提供陈旧的值。重点是“保持开放，避免偷偷摸摸的事情和让人惊讶”。|367818|更新：Ilya+Ryzhenkov问道：“为什么界面不遵循同样的规则？”嗯..。随着我的思考，这一点变得更加混乱。|offset|length|style|BOLD|367819|接口是一种约定，它说“期望一个实现具有一个名为Bar的read属性。”我个人认为，如果我看到一个接口，我就不太可能假设它是只读的。当我在接口上看到get-only属性时，我会将其读作“任何实现都会公开此属性栏”……在基类上，它单击为“Bar+is+a+read-only+property”。当然，从技术上讲，你并没有违反合同..你做的更多。所以从某种意义上说你是对的..最后，我会说：“尽量避免误解的发生”。|367820|entityMap^0|0|0|0|0|0|0|2|0|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Y|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|Z|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|10|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|11|8|@$O|12|P|13|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|14|8|@]|9|@]|A|$]]|$1|U|3|-4|5|6|7|15|8|@]|9|@]|A|$]]]|V|$]]

Because the writer of Baseclass has explicitly declared that Bar has to be a read-only property. It doesn't make sense for derivations to break this contract and make it read-write.

I'm with Microsoft on this one. 
Let's say I'm a new programmer who has been told to code against the Baseclass derivation. i write something that assumes that Bar cannot be written to (since the Baseclass explicitly states that it is a get only property).
Now with your derivation, my code may break. e.g.

<pre><code>public class BarProvider
{ BaseClass _source;
 Bar _currentBar;

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

 public Bar getBar()
 { return _currentBar; }
}
</code></pre>

Since Bar cannot be set as per the BaseClass interface, BarProvider assumes that caching is a safe thing to do - Since Bar cannot be modified. But if set was possible in a derivation, this class could be serving stale values if someone modified the _source object's Bar property externally. The point being 'Be Open, avoid doing sneaky things and surprising people'

Update: Ilya Ryzhenkov asks 'Why don't interfaces play by the same rules then?'
Hmm.. this gets muddier as I think about it. 
An interface is a contract that says 'expect an implementation to have a read property named Bar.' Personally I'm much less likely to make that assumption of read-only if I saw an Interface. When i see a get-only property on an interface, I read it as 'Any implementation would expose this attribute Bar'... on a base-class it clicks as 'Bar is a read-only property'. Of course technically you're not breaking the contract.. you're doing more. So you're right in a sense.. I'd close by saying 'make it as hard as possible for misunderstandings to crop up'.

blocks|key|3370532|text|你也许可以通过创建一个新的属性来解决这个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370533|public+new+int+Bar+
{++++++++++++
++++get+{+return+0;+}
++++set+{}++++++++
}

int+IBase.Bar+{+
++get+{+return+Bar;+}
}|code-block|syntax|javascript|3370534|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You could perhaps go around the problem by creating a new property:

<pre><code>public new int Bar 
{ 
 get { return 0; }
 set {} 
}

int IBase.Bar { 
 get { return Bar; }
}
</code></pre>

blocks|key|367852|text|因为具有只读属性(没有setter)的类可能有很好的理由这样做。例如，可能没有任何底层数据存储。允许你创建一个setter来打破这个类所设定的约定。这只是一个糟糕的OOP。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|367853|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Because a class that has a read-only property (no setter) probably has a good reason for it. There might not be any underlying datastore, for example. Allowing you to create a setter breaks the contract set forth by the class. It's just bad OOP.

blocks|key|3157711|text|我可以理解你的所有观点，但实际上，在这种情况下，C#+3.0的自动属性将变得毫无用处。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157712|你不能这样做：|3157713|public+class+ConcreteClass+:+BaseClass
{
++++public+override+int+Bar
++++{
++++++++get;
++++++++private+set;
++++}
}|code-block|syntax|javascript|3157714|国际海事组织，C#不应该限制这样的情况。开发人员有责任相应地使用它。|3157715|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|O|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

I can understand all your points, but effectively, C# 3.0's automatic properties get useless in that case.

You can't do anything like that:

<pre><code>public class ConcreteClass : BaseClass
{
 public override int Bar
 {
 get;
 private set;
 }
}
</code></pre>

IMO, C# should not restrict such scenarios. It's the responsibility of the developer to use it accordingly.

blocks|key|3157810|text|我认为主要原因很简单，因为语法太明确了，不能以其他方式工作。这段代码：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157811|public+override+int+MyProperty+{+get+{+...+}+set+{+...+}+}|code-block|syntax|javascript|3157812|非常明确，get和set都是重写。基类中没有set，所以编译器会报错。就像你不能覆盖基类中没有定义的方法一样，你也不能覆盖setter。|offset|length|style|CODE|3157813|您可能会说编译器应该猜测您的意图，并仅将覆盖应用于可以覆盖的方法(即本例中的getter+)，但这违反了C#设计原则之一-编译器不能猜测您的意图，因为它可能在您不知道的情况下猜测错误。|3157814|我认为下面的语法可能会做得很好，但正如Eric+Lippert一直说的那样，实现这样一个次要的功能仍然需要大量的努力……|3157815|public+int+MyProperty
{
++++override+get+{+...+}+//+not+valid+C#
++++set+{+...+}
}|3157816|或者，对于自动实现的属性，|3157817|public+int+MyProperty+{+override+get;+set;+}+//+not+valid+C#|3157818|entityMap^0|0|0|5|3|9|3|M|3|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|Z|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|10|8|@$I|11|J|12|K|L]|$I|13|J|14|K|L]|$I|15|J|16|K|L]]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|D|7|19|8|@]|9|@]|A|$E|F]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|D|7|1B|8|@]|9|@]|A|$E|F]]|$1|W|3|-4|5|6|7|1C|8|@]|9|@]|A|$]]]|X|$]]

I think the main reason is simply that the syntax is too explicit for this to work any other way. This code:
<pre><code>public override int MyProperty { get { ... } set { ... } }
</code></pre>
is quite explicit that both the <code>get</code> and the <code>set</code> are overrides. There is no <code>set</code> in the base class, so the compiler complains. Just like you can't override a method that's not defined in the base class, you can't override a setter either.
You might say that the compiler should guess your intention and only apply the override to the method that can be overridden (i.e. the getter in this case), but this goes against one of the C# design principles - that the compiler must not guess your intentions, because it may guess wrong without you knowing.
I think the following syntax might do nicely, but as Eric Lippert keeps saying, implementing even a minor feature like this is still a major amount of effort...
<pre><code>public int MyProperty
{
 override get { ... } // not valid C#
 set { ... }
}
</code></pre>
or, for autoimplemented properties,
<pre><code>public int MyProperty { override get; set; } // not valid C#
</code></pre>

blocks|key|3370661|text|这不是不可能的。你只需要在你的属性中使用"new“关键字。例如,|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370662|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;
++++++++++++}
++++++++}
++++}
}|code-block|syntax|javascript|3370663|似乎这种方法满足了这一讨论的双方。使用"new“打破了基类实现和子类实现之间的契约。当一个类可以有多个契约(通过接口或基类)时，这是必要的。|3370664|希望这能有所帮助|3370665|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

This is not impossible. You simply have to use the "new" keyword in your property. For example,

<pre><code>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;
 }
 }
 }
}
</code></pre>

It appears as if this approach satisfies both sides of this discussion. Using "new" breaks the contract between the base class implementation and the subclass implementation. This is necessary when a Class can have multiple contracts (either via interface or base class). 

Hope this helps

blocks|key|364899|text|今天我碰巧遇到了同样的问题，我想我有一个非常合理的理由想要这样做。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364900|首先，我想说的是，拥有get-only属性并不一定会转化为只读。我把它解释为“从这个接口/抽象类你可以得到这个值”，这并不意味着接口/抽象类的某些实现不需要用户/程序显式地设置这个值。抽象类用于实现所需功能的一部分。我完全看不出为什么继承的类不能在不违反任何约定的情况下添加setter。|364901|下面是我今天所需要的一个简化示例。我最终不得不在我的界面中添加一个setter来解决这个问题。添加设置器而不添加SetProp方法的原因是，接口的一个特定实现使用DataContract/DataMember进行Prop的序列化，如果我仅仅为了序列化的目的而必须添加另一个属性，这将变得不必要地复杂。|364902|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
++++}
}|code-block|syntax|javascript|364903|我知道这只是一篇“我的2分钱”的帖子，但我觉得与原始的帖子一样，试图合理地解释这是一件好事对我来说似乎很奇怪，特别是考虑到当直接从接口继承时，同样的限制并不适用。|364904|此外，关于使用new而不是override的提法在这里不适用，它根本不起作用，即使它起作用，也不会给你想要的结果，也就是接口所描述的虚拟getter。|364905|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|S|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|T|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

I stumbled across the very same problem today and I think I have a very valid reason for wanting this.
First I'd like to argue that having a get-only property doesn't necessarily translate into read-only. I interpret it as &quot;From this interface/abstract class you can get this value&quot;, that doesn't mean that some implementation of that interface/abstract class won't need the user/program to set this value explicitly. Abstract classes serve the purpose of implementing part of the needed functionality. I see absolutely no reason why an inherited class couldn't add a setter without violating any contracts.
The following is a simplified example of what I needed today. I ended up having to add a setter in my interface just to get around this. The reason for adding the setter and not adding, say, a SetProp method is that one particular implementation of the interface used DataContract/DataMember for serialization of Prop, which would have been made needlessly complicated if I had to add another property just for the purpose of serialization.
<pre><code>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 = &quot;BTest&quot;;
 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 = &quot;CTest&quot;;
 public override string Prop
 {
 get { return foo; }
 // set; // Not needed
 }
}
</code></pre>
I know this is just a &quot;my 2 cents&quot; post, but I feel with the original poster and trying to rationalize that this is a good thing seems odd to me, especially considering that the same limitations doesn't apply when inheriting directly from an interface.
Also the mention about using new instead of override does not apply here, it simply doesn't work and even if it did it wouldn't give you the result wanted, namely a virtual getter as described by the interface.

blocks|key|3157953|text|问题是，无论出于什么原因，Microsoft决定应该有三种不同类型的属性:只读、只写和读写，其中只有一种可以在给定的上下文中与给定的签名一起存在；属性只能被相同声明的属性覆盖。要做您想做的事情，需要创建两个具有相同名称和签名的属性--其中一个是只读的，另一个是读写的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3157954|就我个人而言，我希望“属性”的整个概念能够被废除，除了类似属性的语法可以被用作调用"get“和"set”方法的语法糖。这不仅方便了“add+set”选项，还允许“get”返回与“set”不同的类型。虽然这样的功能不会经常使用，但有时让“get”方法返回包装器对象，而“set”方法可以接受包装器或实际数据，这可能会很有用。|3157955|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The problem is that for whatever reason Microsoft decided that there should be three distinct types of properties: read-only, write-only, and read-write, only one of which may exist with a given signature in a given context; properties may only be overridden by identically-declared properties. To do what you want it would be necessary to create two properties with the same name and signature--one of which was read-only, and one of which was read-write.

Personally, I wish that the whole concept of "properties" could be abolished, except that property-ish syntax could be used as syntactic sugar to call "get" and "set" methods. This would not only facilitate the 'add set' option, but would also allow for 'get' to return a different type from 'set'. While such an ability wouldn't be used terribly often, it could sometimes be useful to have a 'get' method return a wrapper object while the 'set' could accept either a wrapper or actual data.

blocks|key|3370781|text|基类中的只读属性指示此属性表示始终可以从类中确定的值(例如，与对象的(db-)上下文匹配的枚举值)。因此，确定值的责任停留在类中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370782|在这里添加setter会导致一个尴尬的问题:如果您将该值设置为任何其他值，而不是它已经具有的单个可能值，则应该会发生验证错误。|3370783|不过，规则通常也有例外。例如，在一个派生类中，很可能上下文将可能的枚举值缩小到10个值中的3个，但是这个对象的用户仍然需要决定哪一个是正确的。派生类需要将确定值的责任委托给此对象的用户。实现的重要一点是，此对象的用户应该很好地意识到此异常，并承担设置正确值的责任。|offset|length|style|BOLD|3370784|在这种情况下，我的解决方案是将属性保留为只读，并向派生类添加一个新的可读写属性以支持异常。对原始属性的覆盖将只返回新属性的值。新属性可以具有适当的名称，以正确指示此异常的上下文。|3370785|这也支持了Gishu的一句名言：“让误解尽可能地突然出现”。|3370786|entityMap^0|0|0|2L|2|2X|E|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@$F|S|G|T|H|I]|$F|U|G|V|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|O|$]]

A read-only property in the base class indicates that this property represents a value that can always be determined from within the class (for example an enum value matching the (db-)context of an object). So the responsibillity of determining the value stays within the class. 

Adding a setter would cause an awkward issue here: 
A validation error should occur if you set the value to anything else than the single possible value it already has.

Rules often have exceptions, though. It is very well possible that for example in one derived class the context narrows the possible enum values down to 3 out of 10, yet the user of this object still needs to decide which one is correct. The derived class needs to delegate the responsibillity of determining the value to the user of this object.
Important to realize is that the user of this object should be well aware of this exception and assume the responsibillity to set the correct value.

My solution in these kind of situations would be to leave the property read-only and add a new read-write property to the derived class to support the exception.
The override of the original property will simply return the value of the new property.
The new property can have a proper name indicating the context of this exception properly.

This also supports the valid remark: "make it as hard as possible for misunderstandings to crop up" by Gishu.

blocks|key|3370816|text|我同意不能覆盖派生类型中的getter是一种反模式。Read-Only指定缺少实现，而不是纯函数的契约(从最高投票结果中隐含)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3370817|我怀疑微软有这个限制，要么是因为推广了同样的误解，要么是因为简化了语法；不过，现在这个作用域可以单独应用于get或set，也许我们可以希望override也可以。|3370818|最高投票结果表明的误解，即只读属性应该以某种方式比读/写属性更“纯粹”，这是荒谬的。简单地看一下框架中的许多常见的只读属性；值不是常量/纯函数；例如，DateTime.Now是只读的，而不是纯函数值。试图“缓存”只读属性的值，假设它下次将返回相同的值，这是有风险的。|3370819|在任何情况下，我都使用了以下策略之一来克服这一限制；这两种策略都不是很完美，但可以让您克服这种语言缺陷：|3370820|+++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;
+++}|code-block|syntax|javascript|3370821|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|Q|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|R|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|S|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|T|8|@]|9|@]|A|$]]]|N|$]]

I agree that not being able to override a getter in a derived type is an anti-pattern. Read-Only specifies lack of implementation, not a contract of a pure functional (implied by the top vote answer).

I suspect Microsoft had this limitation either because the same misconception was promoted, or perhaps because of simplifying grammar; though, now that scope can be applied to get or set individually, perhaps we can hope override can be too.

The misconception indicated by the top vote answer, that a read-only property should somehow be more "pure" than a read/write property is ridiculous. Simply look at many common read only properties in the framework; the value is not a constant / purely functional; for example, DateTime.Now is read-only, but anything but a pure functional value. An attempt to 'cache' a value of a read only property assuming it will return the same value next time is risky.

In any case, I've used one of the following strategies to overcome this limitation; both are less than perfect, but will allow you to limp beyond this language deficiency:

<pre><code> 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;
 }
</code></pre>

blocks|key|368049|text|为了使用反射实现这一点，这里有一个解决方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|368050|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);
}|code-block|syntax|javascript|368051|这样，我们就可以在只读的属性上设置对象值。不过，可能并不是所有的场景都能工作！|368052|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Here is a work-around in order to achieve this using Reflection:

<pre><code>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);
}
</code></pre>

This way we can set object value on a property that is readonly. Might not work in all the scenarios though!

blocks|key|364560|text|这是可能的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|364561|tl;dr–如果需要，您可以使用setter重写get-only方法。它基本上就是：|offset|length|style|BOLD|364562|364563|创建一个new属性，该属性具有使用相同名称的get和set。|ordered-list-item|CODE|364564|364565|对新get.的别名执行|364566|override操作之前的get|364567|364568|这使我们能够使用get/set覆盖属性，即使它们的基本定义中缺少设置器。|364569|364570|情况:预先存在的get-only属性。|364571|你有一些不能修改的类结构。也许它只是一个类，或者它是一个预先存在的继承树。不管是哪种情况，您都想将set方法添加到属性中，但做不到。|364572|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;+}+}
}|code-block|syntax|javascript|364573|364574|问题:无法使用get/set对get-only执行override操作。|364575|您希望使用get/set属性执行override，但它不能编译。|364576|public+class+C+:+B
{
++++private+int+_x;
++++public+override+int+X
++++{
++++++++get+{+return+_x;+}
++++++++set+{+_x+=+value;+}+++//++Won't+compile
++++}
}|364577|364578|解决方案:使用abstract中间层。|364579|虽然不能直接使用get/set属性进行override，但可以|364580|364581|创建同名的new+get/set属性。|364582|364583|使用新的|364584|override方法的访问器对旧的get方法执行|364585|override操作，以确保consistency.|364586|364587|364588|因此，首先要编写abstract中间层：|364589|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;+}
}|364590|然后，编写不能在前面编译的类。这次将编译它，因为您实际上并没有对get-only属性执行override操作；相反，您使用new关键字替换了它。|364591|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;+}+}
}|364592|364593|结果:一切正常！|364594|var+d+=+new+D();

var+a+=+d+as+A;
var+b+=+d+as+B;
var+c+=+d+as+C;

Print(a.X);++++++//+Prints+"0",+the+default+value+of+an+int.
Print(b.X);++++++//+Prints+"0",+the+default+value+of+an+int.
Print(c.X);++++++//+Prints+"0",+the+default+value+of+an+int.
Print(d.X);++++++//+Prints+"0",+the+default+value+of+an+int.

//+a.X+=+7;++++++//+Won't+compile:+A.X+doesn't+have+a+setter.
//+b.X+=+7;++++++//+Won't+compile:+B.X+doesn't+have+a+setter.
//+c.X+=+7;++++++//+Won't+compile:+C.X+doesn't+have+a+setter.
d.X+=+7;+++++++++//+Compiles,+because+D.X+does+have+a+setter.

Print(a.X);++++++//+Prints+"7",+because+7+was+set+through+D.X.
Print(b.X);++++++//+Prints+"7",+because+7+was+set+through+D.X.
Print(c.X);++++++//+Prints+"7",+because+7+was+set+through+D.X.
Print(d.X);++++++//+Prints+"7",+because+7+was+set+through+D.X.|364595|364596|讨论。|364597|此方法允许您向get-only属性添加set方法。你也可以用它来做一些事情，比如：|364598|364599|将任何属性更改为get-only、set-only或get--set属性，而不管它在基类中是什么。|364600|364601|364602|更改派生类中方法的返回类型。|364603|364604|主要的缺点是有更多的代码要做，并且在继承树中有额外的abstract+class。对于接受参数的构造函数来说，这可能有点麻烦，因为这些参数必须复制/粘贴到中间层中。|364605|364606|额外的好处:你可以改变属性的返回类型。|364607|作为额外的好处，您还可以根据需要更改返回类型。|364608|364609|如果基定义是get-only，则可以使用派生程度更高的返回类型。|unordered-list-item|364610|364611|364612|如果基定义是set-only，则可以使用派生较少的返回类型。|364613|364614|364615|如果基定义已经是get/set，则：|364616|364617|-+you+can+use+a+more-derived+return+type+_**if**_+you+make+it+`set`-only;|364618|-+you+can+use+a+less-derived+return+type+_**if**_+you+make+it+`get`-only.|364619|在所有情况下，如果您愿意，都可以保持相同的返回类型。|364620|entityMap^0|0|0|6|0|0|4|3|M|3|Q|3|0|0|2|3|0|0|8|D|3|0|0|8|3|C|3|0|0|8|3|0|1D|3|0|0|0|7|3|B|3|F|3|P|8|0|5|3|9|3|G|8|0|0|0|7|8|0|8|3|C|3|J|8|0|0|5|3|9|3|D|3|0|0|0|0|8|H|3|1|0|8|1|0|0|8|8|0|0|W|3|18|8|1P|3|0|0|0|0|0|0|0|7|3|J|3|0|0|8|3|H|3|Q|3|V|3|0|0|0|0|0|Q|E|0|0|0|0|0|6|3|0|0|0|6|3|0|0|0|8|3|C|3|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|3A|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|3B|8|@$D|3C|E|3D|F|G]]|9|@]|A|$]]|$1|H|3|-4|5|6|7|3E|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|3F|8|@$D|3G|E|3H|F|L]|$D|3I|E|3J|F|L]|$D|3K|E|3L|F|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|3M|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|3N|8|@$D|3O|E|3P|F|L]]|9|@]|A|$]]|$1|P|3|Q|5|K|7|3Q|8|@$D|3R|E|3S|F|L]|$D|3T|E|3U|F|L]]|9|@]|A|$]]|$1|R|3|-4|5|6|7|3V|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|3W|8|@$D|3X|E|3Y|F|L]|$D|3Z|E|40|F|L]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|41|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|42|8|@$D|43|E|44|F|L]]|9|@]|A|$]]|$1|X|3|Y|5|6|7|45|8|@$D|46|E|47|F|L]]|9|@]|A|$]]|$1|Z|3|10|5|11|7|48|8|@]|9|@]|A|$12|13]]|$1|14|3|-4|5|6|7|49|8|@]|9|@]|A|$]]|$1|15|3|16|5|6|7|4A|8|@$D|4B|E|4C|F|L]|$D|4D|E|4E|F|L]|$D|4F|E|4G|F|L]|$D|4H|E|4I|F|L]]|9|@]|A|$]]|$1|17|3|18|5|6|7|4J|8|@$D|4K|E|4L|F|L]|$D|4M|E|4N|F|L]|$D|4O|E|4P|F|L]]|9|@]|A|$]]|$1|19|3|1A|5|11|7|4Q|8|@]|9|@]|A|$12|13]]|$1|1B|3|-4|5|6|7|4R|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|4S|8|@$D|4T|E|4U|F|L]]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|4V|8|@$D|4W|E|4X|F|L]|$D|4Y|E|4Z|F|L]|$D|50|E|51|F|L]]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|52|8|@]|9|@]|A|$]]|$1|1H|3|1I|5|K|7|53|8|@$D|54|E|55|F|L]|$D|56|E|57|F|L]|$D|58|E|59|F|L]]|9|@]|A|$]]|$1|1J|3|-4|5|6|7|5A|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|5B|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|K|7|5C|8|@$D|5D|E|5E|F|L]|$D|5F|E|5G|F|L]]|9|@]|A|$]]|$1|1O|3|1P|5|K|7|5H|8|@$D|5I|E|5J|F|L]]|9|@]|A|$]]|$1|1Q|3|-4|5|6|7|5K|8|@]|9|@]|A|$]]|$1|1R|3|-4|5|6|7|5L|8|@]|9|@]|A|$]]|$1|1S|3|1T|5|6|7|5M|8|@$D|5N|E|5O|F|L]]|9|@]|A|$]]|$1|1U|3|1V|5|11|7|5P|8|@]|9|@]|A|$12|13]]|$1|1W|3|1X|5|6|7|5Q|8|@$D|5R|E|5S|F|L]|$D|5T|E|5U|F|L]|$D|5V|E|5W|F|L]]|9|@]|A|$]]|$1|1Y|3|1Z|5|11|7|5X|8|@]|9|@]|A|$12|13]]|$1|20|3|-4|5|6|7|5Y|8|@]|9|@]|A|$]]|$1|21|3|22|5|6|7|5Z|8|@]|9|@]|A|$]]|$1|23|3|24|5|11|7|60|8|@]|9|@]|A|$12|13]]|$1|25|3|-4|5|6|7|61|8|@]|9|@]|A|$]]|$1|26|3|27|5|6|7|62|8|@]|9|@]|A|$]]|$1|28|3|29|5|6|7|63|8|@$D|64|E|65|F|L]|$D|66|E|67|F|L]]|9|@]|A|$]]|$1|2A|3|-4|5|6|7|68|8|@]|9|@]|A|$]]|$1|2B|3|2C|5|K|7|69|8|@$D|6A|E|6B|F|L]|$D|6C|E|6D|F|L]|$D|6E|E|6F|F|L]|$D|6G|E|6H|F|L]]|9|@]|A|$]]|$1|2D|3|-4|5|6|7|6I|8|@]|9|@]|A|$]]|$1|2E|3|-4|5|6|7|6J|8|@]|9|@]|A|$]]|$1|2F|3|2G|5|K|7|6K|8|@]|9|@]|A|$]]|$1|2H|3|-4|5|6|7|6L|8|@]|9|@]|A|$]]|$1|2I|3|2J|5|6|7|6M|8|@$D|6N|E|6O|F|L]]|9|@]|A|$]]|$1|2K|3|-4|5|6|7|6P|8|@]|9|@]|A|$]]|$1|2L|3|2M|5|6|7|6Q|8|@]|9|@]|A|$]]|$1|2N|3|2O|5|6|7|6R|8|@]|9|@]|A|$]]|$1|2P|3|-4|5|6|7|6S|8|@]|9|@]|A|$]]|$1|2Q|3|2R|5|2S|7|6T|8|@$D|6U|E|6V|F|L]]|9|@]|A|$]]|$1|2T|3|-4|5|6|7|6W|8|@]|9|@]|A|$]]|$1|2U|3|-4|5|6|7|6X|8|@]|9|@]|A|$]]|$1|2V|3|2W|5|2S|7|6Y|8|@$D|6Z|E|70|F|L]]|9|@]|A|$]]|$1|2X|3|-4|5|6|7|71|8|@]|9|@]|A|$]]|$1|2Y|3|-4|5|6|7|72|8|@]|9|@]|A|$]]|$1|2Z|3|30|5|2S|7|73|8|@$D|74|E|75|F|L]|$D|76|E|77|F|L]]|9|@]|A|$]]|$1|31|3|-4|5|6|7|78|8|@]|9|@]|A|$]]|$1|32|3|33|5|11|7|79|8|@]|9|@]|A|$12|13]]|$1|34|3|35|5|11|7|7A|8|@]|9|@]|A|$12|13]]|$1|36|3|37|5|6|7|7B|8|@]|9|@]|A|$]]|$1|38|3|-4|5|6|7|7C|8|@]|9|@]|A|$]]]|39|$]]

<h1>It's possible.</h1>
tl;dr– You can override a get-only method with a setter if you want. It's basically just:
<ol>
<li>Create a <code>new</code> property that has both a <code>get</code> and a <code>set</code> using the same name.
</li>
<li><code>override</code> the prior <code>get</code> to alias the new <code>get</code>.
</li>
</ol>
This enables us to override properties with <code>get</code>/<code>set</code> even if they lacked a setter in their base definition.
<hr />
<h3>Situation: Pre-existing <code>get</code>-only property.</h3>
You have some class structure that you can't modify. Maybe it's just one class, or it's a pre-existing inheritance tree. Whatever the case, you want to add a <code>set</code> method to a property, but can't.
<pre><code>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; } }
}
</code></pre>
<hr />
<h3>Problem: Can't <code>override</code> the <code>get</code>-only with <code>get</code>/<code>set</code>.</h3>
You want to <code>override</code> with a <code>get</code>/<code>set</code> property, but it won't compile.
<pre><code>public class C : B
{
 private int _x;
 public override int X
 {
 get { return _x; }
 set { _x = value; } // Won't compile
 }
}
</code></pre>
<hr />
<h3>Solution: Use an <code>abstract</code> intermediate layer.</h3>
While you can't directly <code>override</code> with a <code>get</code>/<code>set</code> property, you can:
<ol>
<li>Create a <code>new</code> <code>get</code>/<code>set</code> property with the same name.
</li>
<li><code>override</code> the old <code>get</code> method with an accessor to the new <code>get</code> method to ensure consistency.
</li>
</ol>
So, first you write the <code>abstract</code> intermediate layer:
<pre><code>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; }
}
</code></pre>
Then, you write the class that wouldn't compile earlier. It'll compile this time because you're not actually <code>override</code>'ing the <code>get</code>-only property; instead, you're replacing it using the <code>new</code> keyword.
<pre><code>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; } }
}
</code></pre>
<hr />
<h3>Result: Everything works!</h3>
<pre><code>var d = new D();

var a = d as A;
var b = d as B;
var c = d as C;

Print(a.X); // Prints &quot;0&quot;, the default value of an int.
Print(b.X); // Prints &quot;0&quot;, the default value of an int.
Print(c.X); // Prints &quot;0&quot;, the default value of an int.
Print(d.X); // Prints &quot;0&quot;, the default value of an int.

// a.X = 7; // Won't compile: A.X doesn't have a setter.
// b.X = 7; // Won't compile: B.X doesn't have a setter.
// c.X = 7; // Won't compile: C.X doesn't have a setter.
d.X = 7; // Compiles, because D.X does have a setter.

Print(a.X); // Prints &quot;7&quot;, because 7 was set through D.X.
Print(b.X); // Prints &quot;7&quot;, because 7 was set through D.X.
Print(c.X); // Prints &quot;7&quot;, because 7 was set through D.X.
Print(d.X); // Prints &quot;7&quot;, because 7 was set through D.X.
</code></pre>
<hr />
<h3>Discussion.</h3>
This method allows you to add <code>set</code> methods to <code>get</code>-only properties. You can also use it to do stuff like:
<ol>
<li>Change any property into a <code>get</code>-only, <code>set</code>-only, or <code>get</code>-and-<code>set</code> property, regardless of what it was in a base class.
</li>
<li>Change the return type of a method in derived classes.
</li>
</ol>
The main drawbacks are that there's more coding to do and an extra <code>abstract class</code> in the inheritance tree. This can be a bit annoying with constructors that take parameters because those have to be copy/pasted in the intermediate layer.
<hr />
<h3>Bonus: You can change the property's return-type.</h3>
As a bonus, you can also change the return type if you want.
<ul>
<li>If the base definition was <code>get</code>-only, then you can use a more-derived return type.
</li>
<li>If the base definition was <code>set</code>-only, then you can use a less-derived return type.
</li>
<li>If the base definition was already <code>get</code>/<code>set</code>, then:
<ul>
<li>you can use a more-derived return type if you make it <code>set</code>-only;
</li>
<li>you can use a less-derived return type if you make it <code>get</code>-only.
</li>
</ul>
</li>
</ul>
In all cases, you can keep the same return type if you want.

blocks|key|365002|text|您应该更改您的问题标题，以详细说明您的问题仅与覆盖抽象属性有关，或者您的问题与一般覆盖类的get-only属性有关。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|365003|365004|如果以前的为(重写抽象属性)|offset|length|style|BOLD|365005|那个代码是没用的。基类本身不应该告诉您强制覆盖Get-Only属性(可能是一个接口)。基类提供可能需要来自实现类的特定输入的公共功能。因此，公共功能可以调用抽象属性或方法。在给定的情况下，常见的功能方法应该要求您覆盖抽象方法，例如：|365006|public+int+GetBar(){}|code-block|syntax|javascript|365007|但是如果你无法控制它，并且基类的功能是从它自己的公共属性读取的(奇怪的)，那么就这样做：|365008|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;
++++}
}|365009|我想指出(奇怪的)评论:我想说一个最佳实践是一个类不使用它自己的公共属性，而是使用它的私有/受保护字段(如果存在)。所以这是一个更好的模式：|365010|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;+}
}|365011|365012|如果后者为，则为(重写类的get-only属性)|365013|每个非抽象属性都有一个setter。否则它是无用的，你不应该在意使用它。微软不一定要允许你做你想做的事情。原因是:+setter以某种形式存在，您可以轻松地完成您想要的Veerryy。|365014|基类，或者任何可以用{get;}读取属性的类，都有为该属性公开了某种类型的设置器。元数据将如下所示：|CODE|365015|public+abstract+class+BaseClass
{
++++public+int+Bar+{+get;+}
}|365016|但实现将具有复杂性的两个极端：|365017|复杂度最低：|365018|public+abstract+class+BaseClass
{
++++private+int+_bar;
++++public+int+Bar+{+
++++++++get{
++++++++++++return+_bar;
++++++++}}
++++public+void+SetBar(int+value)+{+_bar+=+value;+}
}|365019|最复杂的：|365020|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+%2B+_kthx;+}
++++}
++++public+bool+TryDoSomethingBaz(MyEnum+whatever,+int+input)
++++{
++++++++switch+(whatever)
++++++++{
++++++++++++case+MyEnum.lol:
++++++++++++++++_baz+=+_lawl+%2B+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,
}|365021|我的意思是，无论哪种方式，你都暴露了setter。在您的例子中，您可能希望重写int+Bar，因为您不希望基类处理它，没有权限检查它是如何处理它的，或者被要求违背您的意愿快速处理一些代码。|365022|后一代和前一代中的(结论)|365023|长话短说:微软没有必要改变任何事情。您可以选择如何设置您的实现类，以及在不使用构造函数的情况下，使用所有基类或不使用基类。|365024|entityMap^0|0|0|6|8|0|0|38|0|0|0|18|0|0|0|1Y|0|0|0|0|5|8|G|0|0|2K|0|0|1E|A|6|0|0|0|F|0|0|6|0|0|0|5|0|0|0|2M|13|7|0|0|7|9|4|0|0|1P|0^^$0|@$1|2|3|4|5|6|7|1P|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|C|3|D|5|6|7|1R|8|@$E|1S|F|1T|G|H]]|9|@]|A|$]]|$1|I|3|J|5|6|7|1U|8|@$E|1V|F|1W|G|H]]|9|@]|A|$]]|$1|K|3|L|5|M|7|1X|8|@]|9|@]|A|$N|O]]|$1|P|3|Q|5|6|7|1Y|8|@$E|1Z|F|20|G|H]]|9|@]|A|$]]|$1|R|3|S|5|M|7|21|8|@]|9|@]|A|$N|O]]|$1|T|3|U|5|6|7|22|8|@$E|23|F|24|G|H]]|9|@]|A|$]]|$1|V|3|W|5|M|7|25|8|@]|9|@]|A|$N|O]]|$1|X|3|-4|5|6|7|26|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|27|8|@$E|28|F|29|G|H]|$E|2A|F|2B|G|H]]|9|@]|A|$]]|$1|10|3|11|5|6|7|2C|8|@$E|2D|F|2E|G|H]]|9|@]|A|$]]|$1|12|3|13|5|6|7|2F|8|@$E|2G|F|2H|G|H]|$E|2I|F|2J|G|14]]|9|@]|A|$]]|$1|15|3|16|5|M|7|2K|8|@]|9|@]|A|$N|O]]|$1|17|3|18|5|6|7|2L|8|@$E|2M|F|2N|G|H]]|9|@]|A|$]]|$1|19|3|1A|5|6|7|2O|8|@$E|2P|F|2Q|G|H]]|9|@]|A|$]]|$1|1B|3|1C|5|M|7|2R|8|@]|9|@]|A|$N|O]]|$1|1D|3|1E|5|6|7|2S|8|@$E|2T|F|2U|G|H]]|9|@]|A|$]]|$1|1F|3|1G|5|M|7|2V|8|@]|9|@]|A|$N|O]]|$1|1H|3|1I|5|6|7|2W|8|@$E|2X|F|2Y|G|H]|$E|2Z|F|30|G|14]]|9|@]|A|$]]|$1|1J|3|1K|5|6|7|31|8|@$E|32|F|33|G|H]|$E|34|F|35|G|H]]|9|@]|A|$]]|$1|1L|3|1M|5|6|7|36|8|@$E|37|F|38|G|H]]|9|@]|A|$]]|$1|1N|3|-4|5|6|7|39|8|@]|9|@]|A|$]]]|1O|$]]

You should alter your question title to either detail that your question is solely in regards to overriding an abstract property, or that your question is in regards to generally overriding a class's get-only property.

<hr>

If the former (overriding an abstract property)

That code is useless. A base class alone shouldn't tell you that you're forced to override a Get-Only property (Perhaps an Interface). A base class provides common functionality which may require specific input from an implementing class. Therefore, the common functionality may make calls to abstract properties or methods. In the given case, the common functionality methods should be asking for you to override an abstract method such as:

<pre><code>public int GetBar(){}
</code></pre>

But if you have no control over that, and the functionality of the base class reads from its own public property (weird), then just do this:

<pre><code>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;
 }
}
</code></pre>

I want to point out the (weird) comment: I would say a best-practice is for a class to not use its own public properties, but to use its private/protected fields when they exist. So this is a better pattern:

<pre><code>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; }
}
</code></pre>

<hr>

If the latter (overriding a class's get-only property)

Every non-abstract property has a setter. Otherwise it's useless and you shouldn't care to use it. Microsoft doesn't have to allow you to do what you want. Reason being: the setter exists in some form or another, and you can accomplish what you want Veerryy easily.

The base class, or any class where you can read a property with <code>{get;}</code>, has SOME sort of exposed setter for that property. The metadata will look like this:

<pre><code>public abstract class BaseClass
{
 public int Bar { get; }
}
</code></pre>

But the implementation will have two ends of the spectrum of complexity:

Least Complex:

<pre><code>public abstract class BaseClass
{
 private int _bar;
 public int Bar { 
 get{
 return _bar;
 }}
 public void SetBar(int value) { _bar = value; }
}
</code></pre>

Most Complex:

<pre><code>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; //&lt;-- calculations
 }
}
public enum MyEnum
{
 lol,
 wtf,
}
</code></pre>

My point being, either way, you have the setter exposed. In your case, you may want to override <code>int Bar</code> because you don't want the base class to handle it, don't have access to review how it's handling it, or were tasked to hax some code real quick'n'dirty against your will.

In both Latter and Former (Conclusion)

Long-Story Short: It isn't necessary for Microsoft to change anything. You can choose how your implementing class is set up and, sans the constructor, use all or none of the base class.

blocks|key|368081|text|仅适用于一小部分用例的解决方案，但不管怎样:在C#+6.0中，会自动为被覆盖的getter-only属性添加“只读”设置器。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|368082|public+abstract+class+BaseClass
{
++++public+abstract+int+Bar+{+get;+}
}

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

++++public+ConcreteClass(int+bar)
++++{
++++++++Bar+=+bar;
++++}
}|code-block|syntax|javascript|368083|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

Solution for only a small subset of use cases, but nevertheless: in C# 6.0 "readonly" setter is automatically added for overridden getter-only properties.

<pre><code>public abstract class BaseClass
{
 public abstract int Bar { get; }
}

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

 public ConcreteClass(int bar)
 {
 Bar = bar;
 }
}
</code></pre>

Why is the following C# code not allowed:

<pre><code>public abstract class BaseClass
{
 public abstract int Bar { get;}
}

public class ConcreteClass : BaseClass
{
 public override int Bar
 {
 get { return 0; }
 set {}
 }
}
</code></pre>

<blockquote>
 CS0546 'ConcreteClass.Bar.set': cannot override because 'BaseClass.Bar' does not have an overridable set accessor
</blockquote>

Why is it impossible to override a getter-only property and add a setter?

数据存储

编译器

为什么不允许使用以下C#代码：public abstract class BaseClass{    public abstract int Bar { get;}}public class ConcreteClass : BaseClass{    public override int Bar    {      ...

问为什么不能覆盖仅限getter的属性并添加setter？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不能覆盖仅限getter的属性并添加setter？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么不能覆盖仅限getter的属性并添加setter？
EN