it-swarm.cn

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

为什么不允许使用以下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'没有可覆盖的set访问器

135
ripper234

因为Baseclass的编写者明确声明Bar必须是只读属性。对于推断违反此合同并使其成为读写而言没有意义。

我和微软在这一方面。
假设我是一名新程序员,他被告知要对基类推导进行编码。我写的东西假定Bar不能被写入(因为Baseclass明确声明它是一个get get属性)。现在有了你的推导,我的代码可能会破坏。例如.

public class BarProvider
{ BaseClass _source;
  Bar _currentBar;

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

  public Bar getBar()
  { return _currentBar;  }
}

由于Bar不能按照BaseClass接口进行设置,因此BarProvider假定缓存是安全的事情 - 因为Bar不能被修改。但是如果在派生中设置是可能的,那么如果有人在外部修改_source对象的Bar属性,则此类可能会提供过时值。关键是' 开放,避免做鬼鬼祟祟的事情和令人惊讶的人 '

更新 Ilya Ryzhenkov问'为什么接口不按照相同的规则播放呢?' 嗯..当我想到它时,这变得更加混乱。
接口是一个合同,它说“期望实现具有名为Bar的读取属性”。 个人如果我看到一个接口,我就不太可能做出只读的假设。当我在界面上看到一个get-only属性时,我将其读作“任何实现将公开此属性Bar”...在它所点击的基类上,因为“Bar是一个只读属性”。当然,从技术上讲,你并没有违反合同......你做得更多。因此,从某种意义上说,你是正确的......我最后会说'尽量让误解突然出现'。

1
Gishu

我认为主要原因很简单,语法过于明确,不能以任何其他方式工作。这段代码:

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

非常明确的是getset都是覆盖。基类中没有set,因此编译器会抱怨。就像你不能覆盖未在基类中定义的方法一样,也不能覆盖setter。

你可能会说编译器应该猜测你的意图并且只将覆盖应用于可以被覆盖的方法(在这种情况下是getter),但是这违背了C#设计原则之一 - 编译器不能猜测你的意图,因为如果你不知道它可能会猜错。

我认为以下语法可能做得很好,但正如Eric Lippert所说,实现这样的小功能仍然是一项重大工作......

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

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

public int MyProperty { override get; set; }
34
Roman Starkov

我今天偶然发现了同样的问题,我觉得有一个非常有理由想要这个。

首先,我想争辩说,拥有一个get-only属性并不一定会转换为只读属性。我把它解释为“从这个接口/ abtract你可以得到这个值”,这并不意味着该接口/抽象类的某些实现不需要用户/程序显式设置该值。抽象类用于实现所需功能的一部分。我完全没有理由认为继承的类在没有违反任何合同的情况下无法添加setter。

以下是我今天所需要的简化示例。我最终不得不在我的界面中添加一个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。

19
JJJ

这是可能的

tl; dr - 如果需要,可以使用setter覆盖get-only方法。它基本上只是:

  1. 创建一个new属性,该属性同时具有getset

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

这使我们能够使用get/set覆盖属性,即使它们在基本定义中缺少一个属性。

作为奖励,您还可以根据需要更改返回类型。

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

  • 如果基本定义仅为set-,那么您可以使用较少派生的返回类型。

  • 如果基本定义已经是get/set,那么:

    • 你可以使用更多派生的返回类型 if 你只使它set-;

    • 你可以使用一个较少派生的返回类型 if 你只能使它get-。

在所有情况下,如果需要,您可以保持相同的返回类型。为简单起见,以下示例使用相同的返回类型。

情况:预先存在get- only属性

您有一些无法修改的类结构。也许它只是一个类,或者它是一个预先存在的继承树。无论如何,您都希望向属性添加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; } }
}

问题:不能overrideget-仅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中间层

虽然你不能直接overrideget/set属性,你 can

  1. 创建具有相同名称的newget/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.

当将D视为其基类之一时,一切仍然有效 - 例如, AB。但是,它起作用的原因可能不太明显。

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-和-set属性,无论它在基类中是什么。

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

主要的缺点是在继承树中需要做更多的编码和额外的abstract class。对于带参数的构造函数,这可能有点烦人,因为那些必须在中间层中进行复制/粘贴。

13
Nat

我同意不能在派生类型中覆盖getter是一种反模式。只读指定缺乏实现,而不是纯函数的契约(由最高投票答案暗示)。

我怀疑微软有这个限制要么是因为同样的误解被提升了,要么是因为简化了语法;虽然,既然范围可以应用于单独获取或设置,也许我们可以希望覆盖也可以。

最高投票回答指出的误解是,只读属性应该比读/写属性更“纯粹”是荒谬的。只需查看框架中的许多常见只读属性;价值不是恒定/纯粹的功能;例如,DateTime.Now是只读的,但除了纯函数值之外的任何东西。尝试“缓存”只读属性的值,假设它下次返回相同的值是有风险的。

在任何情况下,我都使用以下策略之一来克服这个限制;两者都不完美,但会让你跛行超越这种语言的不足:

   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;
   }
9
T.Tobler

问题是,无论出于何种原因,Microsoft决定应该有三种不同类型的属性:只读,只写和读写,在给定的上下文中只有一个可能与给定签名一起存在;属性只能由相同声明的属性覆盖。要做你想做的事情,有必要创建两个具有相同名称和签名的属性 - 其中一个是只读的,其中一个是读写的。

就个人而言,我希望可以废除“属性”的整个概念,除了可以使用属性语法作为语法糖来调用“get”和“set”方法。这不仅有助于'添加集'选项,还可以让'get'从'set'返回不同的类型。虽然这种能力不会经常使用,但有时候'get'方法会返回一个包装器对象,而'set'可以接受包装器或实际数据。

1
supercat

我能理解你的所有观点,但实际上,在这种情况下,C#3.0的自动属性变得毫无用处。

你不能做那样的事情:

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

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

1
Thomas Danecker

您可以通过创建新属性来解决问题:

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

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

仅针对一小部分用例的解决方案,但仍然是:在C#6.0中,“readonly”setter会自动添加,以覆盖仅限getter的属性。

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

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

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

您应该将问题标题更改为您的问题仅涉及覆盖抽象属性的详细信息,或者您的问题是关于通常覆盖类的只获取属性的问题。


如果是前者 (覆盖抽象属性)

那段代码没用。单独的基类不应该告诉您,您不得不重写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属性)

每个非抽象的财产都有一个二传手。否则它没用,你不应该关心它。 Microsoft不必允许您执行您想要的操作。理由是:setter以某种形式存在,你可以完成你想要的东西 Veerryy 很容易。

基类或您可以使用{get;}读取属性的任何类具有 _某些_ 类型的该属性的公开setter。元数据将如下所示:

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,因为你不希望基类处理它,没有权限查看它是如何处理它的,或者被委托给某些代码真正快速地反对你的将。

后者和前者 (结论)

长话短说:微软没有必要改变任何东西。您可以选择如何设置实现类,并且不使用构造函数,使用全部或不使用基类。

0
Suamere

以下是使用Reflection实现此目的的解决方法:

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);
}

这样我们就可以在readonly属性上设置对象值。但是可能不适用于所有场景!

0
user2514880