Aşağıdaki C # koduna neden izin verilmiyor:

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' geçersiz kılınabilir bir ayar erişimcisi olmadığından geçersiz kılınamıyor

Çünkü Baseclass'ın yazarı Bar'ın salt okunur bir özellik olması gerektiğini açıkça ilan etti. Türevlerin bu sözleşmeyi kırması ve okuma-yazma yapması mantıklı değildir.

Bu konuda Microsoft ile beraberim.
Diyelim ki Baseclass türevine karşı kod yazması söylenen yeni bir programcıyım. (Baseclass açıkça bir get özelliği olduğunu belirttiği için) Bar için yazılamaz olduğunu varsayan bir şey yazmak. Şimdi türetmenizle kodum kırılabilir. Örneğin

public class BarProvider
{ BaseClass _source;
  Bar _currentBar;

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

  public Bar getBar()
  { return _currentBar;  }
}

Bar BaseClass arabirimine göre ayarlanamadığından, BarProvider önbelleğe almanın güvenli bir şey olduğunu varsayar - Bar değiştirilemez. Ancak bir türevde set mümkün olsaydı, birisi _source nesnesinin Bar özelliğini harici olarak değiştirdiğinde bu sınıf eski değerler sunabilir. ' Açık olun, gizli şeyler yapmaktan ve şaşırtıcı insanlar yapmaktan kaçınmak '

Güncelleme : Ilya Ryzhenkov soruyor 'Neden arayüzler aynı kurallara göre oynamıyor?' Hmm .. bu düşündüğümde daha çamurlu oluyor.
Arayüz, 'bir uygulamanın Bar adında bir okuma özelliğine sahip olmasını bekleyin' yazan bir sözleşmedir. Şahsen ben bir Arayüz görürsem bu salt okunur varsayımını yapmam daha az olasıdır. Bir arabirimde bir salt okunur özelliği gördüğümde, 'Herhangi bir uygulama bu öznitelik Çubuğu'nu açığa çıkaracak' olarak okudum ... 'Bar salt okunur bir özellik' olarak tıkladığı bir temel sınıfta. Tabii teknik olarak sözleşmeyi bozmuyorsunuz .. daha fazlasını yapıyorsunuz. Yani bir anlamda haklısın .. 'Yanlış anlamaların ortaya çıkmasını mümkün olduğunca zorlaştır' diyerek kapatırdım.

Bence asıl sebep, sözdiziminin bunun başka bir şekilde çalışması için çok açık olmasıdır. Bu kod:

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

hem getve hem setde geçersiz kılınan oldukça açıktır . setTemel sınıfta hiç yok , bu yüzden derleyici şikayet ediyor. Tıpkı temel sınıfta tanımlı olmayan bir yöntemi geçersiz kılamamanız gibi, bir ayarlayıcıyı da geçersiz kılamazsınız.

Derleyicinin niyetinizi tahmin etmesi ve yalnızca geçersiz kılma yöntemine geçersiz kılma yöntemini (yani bu durumda alıcı) uygulamanız gerektiğini söyleyebilirsiniz, ancak bu C # tasarım ilkelerinden birine aykırıdır - derleyici niyetlerinizi tahmin etmemelidir , çünkü bilmeden yanlış tahmin edebilir.

Aşağıdaki sözdiziminin iyi yapabileceğini düşünüyorum, ancak Eric Lippert'in söylediği gibi, bunun gibi küçük bir özelliği bile uygulamak hala büyük bir çaba ...

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

veya otomatik olarak uygulanan özellikler için,

public int MyProperty { override get; set; }

Bugün aynı problemle karşılaştım ve bence bunu istemek için çok geçerli bir neden var.

Öncelikle, salt get özelliğine sahip olmanın mutlaka salt okunur hale gelmediğini iddia etmek istiyorum. Ben bu arabirim / soyut sınıfın bazı uygulama bu değeri açıkça ayarlamak için kullanıcı / program gerekmez alışkanlık anlamına gelmez "Bu arabirim / abtract bu değeri alabilirsiniz" olarak yorumlayın. Soyut sınıflar, gerekli işlevselliğin bir kısmını uygulama amacına hizmet eder. Devralınan bir sınıfın herhangi bir sözleşmeyi ihlal etmeden belirleyici ekleyememesi için hiçbir neden göremiyorum.

Aşağıda bugün ihtiyacımın basitleştirilmiş bir örneği var. Sadece bu sorunu çözmek için arayüzüme bir ayarlayıcı eklemek zorunda kaldım. Setter eklemenin ve bir SetProp yönteminin eklenmemesinin nedeni, arabirimin belirli bir uygulamasının, Prop için serileştirilmesi için DataContract / DataMember'i kullanmasıdır; serileştirme.

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

Bunun sadece "2 sentim" bir yazı olduğunu biliyorum, ama orijinal posterle hissediyorum ve bunun iyi bir şey olduğunu rasyonelleştirmeye çalışıyorum, özellikle de doğrudan bir mirastan miras alırken aynı sınırlamaların geçerli olmadığını düşünerek arayüz.

Ayrıca, geçersiz kılma yerine yeni kullanımla ilgili sözler burada geçerli değildir, işe yaramaz ve yapsa bile, arabirim tarafından açıklandığı gibi sanal bir alıcı, istenen sonucu vermez.

Mümkün

tl; dr - İsterseniz bir ayarlayıcıyla salt get yöntemini geçersiz kılabilirsiniz. Temel olarak sadece:

1. Bir oluşturun newa hem sahiptir özelliğini getve setaynı adı kullanarak.

2. Başka bir şey yapmazsanız get, türetilmiş sınıf temel türü üzerinden çağrıldığında eski yöntem çağrılır. Bunu düzeltmek için, yeni yöntemin sonucunu döndürmeye zorlamak üzere eski yöntemde abstractkullanılan bir ara katman ekleyin .overridegetget

Bu, özellikleri temel tanımlarında eksik olsalar bile get/ ile özellikleri geçersiz kılmamızı sağlar set.

Bonus olarak, isterseniz dönüş türünü de değiştirebilirsiniz.

• Temel tanım get-sadece ise, daha türetilmiş bir dönüş türü kullanabilirsiniz.

• Temel tanım set-sadece ise, daha az türetilmiş bir dönüş türü olabilirsiniz.

• Temel tanım zaten get/ setise:

  • Eğer daha türetilmiş dönüş türü kullanabilirsiniz eğer bunu yapmak set-sadece;

  • Eğer daha az türetilmiş dönüş türü kullanabilirsiniz eğer bunu yapmak get-sadece.

Her durumda, isterseniz aynı dönüş türünü koruyabilirsiniz. Aşağıdaki örnekler basitlik için aynı dönüş türünü kullanır.

Durum: Önceden var olan get-sadece mülk

Değiştiremeyeceğiniz bir sınıf yapınız var. Belki de sadece bir sınıftır ya da önceden var olan bir miras ağacıdır. Durum ne olursa olsun, setbir mülke yöntem eklemek istersiniz , ancak yapamazsınız.

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

Sorun: Yapamam -sadece ile /overridegetgetset

overrideBir get/ setözelliği ile istersiniz , ancak derlenmez.

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

Çözüm: abstractAra katman kullanın

Doğrudan overridebir get/ setmülkle yapamasanız da şunları yapabilirsiniz :

1. Aynı ada sahip bir new get/ setözellik oluşturun .

2. overrideeski getyöntemi gettutarlılık sağlamak için yeni yöntem bir erişimci ile .

Yani, önce abstractara katmanı yazıyorsunuz :

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

Sonra, daha önce derlenmeyecek sınıfı yazarsınız. Bu aslında çünkü bu sefer derlersiniz override'ing get-sadece özelliği; bunun yerine, newanahtar kelimeyi kullanarak değiştirebilirsiniz .

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

Sonuç: Her şey işe yarıyor!

Açıkçası, bu amaçlandığı gibi çalışıyor 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.

DTemel sınıflarından biri olarak görüntülerken , her şey hala amaçlandığı gibi çalışır , örneğin Aveya B. Ancak, çalışmasının nedeni biraz daha az belirgin olabilir.

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.

Bununla birlikte, temel sınıf tanımı getsonuçta türetilmiş sınıfın tanımı ile geçersiz kılınır get, bu yüzden hala tamamen tutarlıdır.

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.

Tartışma

Bu yöntem, -only özelliklerine setyöntem eklemenizi sağlar get. Ayrıca, aşağıdakileri yapmak için de kullanabilirsiniz:

1. Temel sınıfta ne olursa olsun, herhangi bir özelliği get-sadece, set-sadece veya get-ve- setözellik olarak değiştirin.

2. Türetilmiş sınıflarda bir yöntemin dönüş türünü değiştirin.

Ana dezavantajları, daha fazla kodlama abstract classve miras ağacında ekstra bir şey olmasıdır . Bu, parametre alan yapıcılar için biraz can sıkıcı olabilir, çünkü bunların ara katmana kopyalanması / yapıştırılması gerekir.

Türetilmiş tipte bir alıcıyı geçersiz kılamamanın bir anti-desen olduğunu kabul ediyorum. Salt Okunur, saf işlevin bir sözleşmesini değil (en yüksek oylama cevabının ima ettiği) uygulama eksikliğini belirtir.

Microsoft'un bu yanlışlığa ya da aynı yanlış anlama teşvik edildiğinden ya da belki de dilbilgisini basitleştirdiği için sahip olduğundan şüpheleniyorum; Ancak, şimdi bu kapsam bireysel olarak almak veya ayarlamak için uygulanabilir, belki de geçersiz kılmanın da olabileceğini umabiliriz.

Üst oylama cevabının gösterdiği yanlış anlama, salt okunur bir özelliğin bir şekilde bir okuma / yazma özelliğinden daha "saf" olması saçmadır. Sadece çerçevedeki birçok yaygın salt okunur özelliğe bakın; değer sabit / tamamen işlevsel değildir; örneğin, DateTime.Now salt okunur, ancak saf işlevsel bir değer dışında bir şey. Bir dahaki sefere aynı değeri döndüreceğini varsayarak salt okunur bir özelliğin değerini 'önbelleğe alma' girişimi risklidir.

Her durumda, bu sınırlamanın üstesinden gelmek için aşağıdaki stratejilerden birini kullandım; her ikisi de mükemmel olmaktan daha az, ancak bu dil eksikliğinin ötesine geçmenize izin verecektir:

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

Belki de yeni bir mülk oluşturarak sorunu çözebilirsiniz:

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

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

Tüm puanlarınızı anlayabiliyorum, ancak etkili bir şekilde, C # 3.0'ın otomatik özellikleri bu durumda işe yaramaz.

Böyle bir şey yapamazsınız:

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

IMO, C # bu tür senaryoları kısıtlamamalıdır. Buna göre kullanmak geliştiricinin sorumluluğundadır.

Sorun şu ki, Microsoft her ne sebeple olursa olsun, üç farklı özellik türü olması gerektiğine karar vermiştir: salt okunur, salt yazılabilir ve okuma-yazma; bunlardan yalnızca biri belirli bir bağlamda belirli bir imzayla var olabilir; özellikler yalnızca aynı şekilde bildirilen özellikler tarafından geçersiz kılınabilir. İstediğinizi yapmak için, biri salt okunur, biri de okuma-yazma olan aynı ad ve imzayla iki özellik oluşturmanız gerekir.

Şahsen, keşke "get" ve "set" yöntemlerini çağırmak için sözdizimsel şeker olarak kullanılabilmesi dışında tüm "özellikler" kavramının kaldırılabilmesini diliyorum. Bu sadece 'set ekle' seçeneğini kolaylaştırmakla kalmayacak, aynı zamanda “get” in “set” ten farklı bir tür döndürmesine izin verecektir. Böyle bir yetenek çok sık kullanılmasa da, bazen 'get' yönteminin bir sarmalayıcı nesnesini döndürmesi yararlı olabilirken, 'set' bir sarmalayıcıyı veya gerçek verileri kabul edebilir.

Reflection kullanarak bunu başarmak için bir çözüm bulabilirsiniz:

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

Bu şekilde, salt okunur bir özellik üzerinde nesne değeri ayarlayabiliriz. Yine de tüm senaryolarda çalışmayabilir!

Soru başlığınızı, sorunuzun yalnızca soyut bir mülkün geçersiz kılınmasıyla ilgili olduğu veya sorunuzun genellikle bir sınıfın salt özellikli mülkünü geçersiz kılma konusundaki ayrıntısına göre değiştirmeniz gerekir.

Önceki (soyut bir özelliği geçersiz kılma)

Bu kod işe yaramaz. Yalnızca bir temel sınıf size Get-Get özelliğini (Belki de bir Arabirim) geçersiz kılmak zorunda olduğunuzu söylememelidir. Temel sınıf, bir uygulama sınıfından belirli girdiler gerektirebilecek ortak işlevsellik sağlar. Bu nedenle, ortak işlevsellik soyut özelliklere veya yöntemlere çağrı yapabilir. Belirli bir durumda, ortak işlevsellik yöntemleri, aşağıdaki gibi soyut bir yöntemi geçersiz kılmanızı istemelidir:

public int GetBar(){}

Ancak bunun üzerinde kontrolünüz yoksa ve temel sınıfın işlevselliği kendi ortak mülkünden (garip) okursa, bunu yapın:

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

(Tuhaf) yorumu belirtmek istiyorum: En iyi uygulama, bir sınıfın kendi genel özelliklerini kullanmaması, ancak özel / korunan alanlarını mevcut olduğunda kullanmasıdır. Yani bu daha iyi bir model:

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

İkincisi ise (bir sınıfın salt özellik özelliğini geçersiz kılma)

Soyut olmayan her mülk bir ayarlayıcıya sahiptir. Aksi takdirde işe yaramaz ve onu kullanmamanız gerekir. Microsoft'un istediğinizi yapmanıza izin vermesi gerekmez. Sebep: ayarlayıcı bir şekilde var olabilir ve Veerryy istediğinizi kolayca başarabilirsiniz .

Taban sınıfı veya bir özelliğini okuyabilir herhangi sınıfı {get;}, sahip BAZI o özellik için maruz setter çeşit. Meta veriler şöyle görünecektir:

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

Ancak uygulamanın karmaşıklık spektrumunun iki ucu olacaktır:

En Küçük Kompleks:

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

En Karmaşık:

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,
}

Demek istediğim, her iki durumda da ayarlayıcıyı açığa çıkarıyorsunuz. Sizin durumunuzda, int Bartemel sınıfın işlemesini istemediğiniz, nasıl işlediğini gözden geçirmek için erişiminiz olmadığından veya iradenize karşı gerçek quick'n'dirty bazı kodları taklit etmek istendiğinden geçersiz kılmak isteyebilirsiniz .

Hem Sonunda hem de Eski'de (Sonuç)

Uzun Öykü Kısa: Microsoft'un hiçbir şeyi değiştirmesi gerekmez. Uygulayıcı sınıfınızın nasıl ayarlanacağını seçebilir ve yapıcıya temel sınıfın tamamını veya hiçbirini kullanamazsınız.

Kullanım durumlarının sadece küçük bir alt kümesi için çözüm, ancak yine de: C # 6.0'da geçersiz kılınan yalnızca alıcı özellikleri için "salt okunur" ayarlayıcı otomatik olarak eklenir.

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

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

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

Çünkü bu, kapsülleme ve uygulama gizleme kavramını kıracaktır. Bir sınıf oluşturduğunuzda, onu gönderdiğinizde ve sınıfınızın tüketicisi sadece başlangıçta bir alıcı sağladığınız bir mülk ayarlayabildiğini düşünün. Uygulamanızda güvenebileceğiniz sınıfınızın değişmezlerini etkili bir şekilde bozar.

Bu imkansız değil. Mülkünüzde "yeni" anahtar kelimeyi kullanmanız yeterlidir. Örneğin,

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

Görünüşe göre bu yaklaşım tartışmanın her iki tarafını da tatmin ediyor. "Yeni" kullanmak, temel sınıf uygulaması ile alt sınıf uygulaması arasındaki sözleşmeyi ihlal eder. Bu, bir Sınıfın birden fazla sözleşmesi olabileceği zaman gereklidir (arabirim veya temel sınıf üzerinden).

Bu yardımcı olur umarım

Temel sınıftaki salt okunur bir özellik, bu özelliğin her zaman sınıf içinden belirlenebilen bir değeri temsil ettiğini gösterir (örneğin, bir nesnenin (db-) bağlamıyla eşleşen bir enum değeri). Dolayısıyla değeri belirlemenin sorumluluğu sınıf içinde kalır.

Bir ayarlayıcı eklemek burada garip bir soruna neden olur: Değeri zaten sahip olduğu olası tek bir değerden başka bir değere ayarlarsanız bir doğrulama hatası oluşmalıdır.

Yine de kuralların istisnaları vardır. Örneğin türetilmiş bir sınıfta bağlamın olası enum değerlerini 10 üzerinden 3'e kadar daraltması çok mümkündür, ancak bu nesnenin kullanıcısının hala hangisinin doğru olduğuna karar vermesi gerekir. Türetilmiş sınıfın, değeri bu nesnenin kullanıcısına belirleme sorumluluğunu devretmesi gerekir. Farkına varmak önemlidir , bu nesnenin kullanıcısının bu istisnanın farkında olması gerekir ve doğru değeri ayarlamak için responsibillity varsayalım.

Bu tür durumlarda benim çözüm özelliği salt okunur bırakmak ve istisna desteklemek için türetilmiş sınıfa yeni bir okuma-yazma özelliği eklemek olacaktır. Orijinal özelliğin geçersiz kılınması, yeni özelliğin değerini döndürür. Yeni özelliğin, bu özel durumun bağlamını doğru şekilde belirten uygun bir adı olabilir.

Bu aynı zamanda geçerli ifadeyi de desteklemektedir: Gishu'nun “yanlış anlamaların ortaya çıkmasını mümkün olduğunca zorlaştırın”.

Çünkü IL düzeyinde, bir okuma / yazma özelliği iki (alıcı ve ayarlayıcı) yöntemine dönüşür.

Geçersiz kılınırken, alttaki arayüzü desteklemeye devam etmelisiniz. Bir ayarlayıcı ekleyebilseydiniz, sınıflarınızın arayüzü söz konusu olduğunda, dış dünyaya görünmez kalacak yeni bir yöntem eklersiniz.

Doğru, yeni bir yöntem eklemek kendi başına uyumluluğu bozmaz, ancak gizli kalacağı için buna izin vermeme kararı mükemmel olur.

Çünkü salt okunur bir özelliğe (ayarlayıcı olmadan) sahip bir sınıfın muhtemelen bunun için iyi bir nedeni vardır. Örneğin, altta yatan herhangi bir veri deposu olmayabilir. Bir ayarlayıcı oluşturmanıza izin vermek, sınıf tarafından belirlenen sözleşmeyi ihlal eder. Sadece kötü OOP.