Dlaczego następujący kod C # nie jest dozwolony:

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”: nie można przesłonić, ponieważ „BaseClass.Bar” nie ma nadpisywalnego akcesorium zestawu

Ponieważ autor klasy Baseclass wyraźnie zadeklarował, że Bar musi być właściwością tylko do odczytu. Nie ma sensu, aby derywaty przerywały ten kontrakt i zmuszały go do odczytu i zapisu.

Jestem w tej sprawie z Microsoftem.
Powiedzmy, że jestem nowym programistą, któremu powiedziano, że mam kodować w oparciu o wyprowadzenie klasy podstawowej. piszę coś, co zakłada, że ​​Bar nie może zostać zapisany (ponieważ klasa bazowa wyraźnie stwierdza, że ​​jest to właściwość tylko do pobrania). Teraz, po twoim wyprowadzeniu, mój kod może się zepsuć. na przykład

public class BarProvider
{ BaseClass _source;
  Bar _currentBar;

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

  public Bar getBar()
  { return _currentBar;  }
}

Ponieważ Bar nie może być ustawiony zgodnie z interfejsem BaseClass, BarProvider zakłada, że ​​buforowanie jest rzeczą bezpieczną - ponieważ Bar nie może być modyfikowany. Ale jeśli set był możliwy w wyprowadzeniu, ta klasa może obsługiwać nieaktualne wartości, jeśli ktoś zmodyfikował zewnętrznie właściwość Bar obiektu _source. Chodzi o to, że „ bądź otwarty, unikaj robienia podstępnych rzeczy i zaskakiwania ludzi ”

Aktualizacja : Ilya Ryzhenkov pyta „Dlaczego więc interfejsy nie działają według tych samych zasad?” Hmm ... kiedy o tym myślę, robi się to bardziej mętne.
Interfejs jest kontraktem, który mówi „spodziewaj się, że implementacja będzie miała właściwość odczytu o nazwie Bar”. Osobiście znacznie rzadziej przyjmę założenie tylko do odczytu, gdy zobaczę interfejs. Kiedy w interfejsie widzę właściwość tylko do pobierania, odczytuje się ją jako „Każda implementacja ujawniłaby ten atrybut Bar” ... w klasie bazowej, którą klika jako „Bar jest właściwością tylko do odczytu”. Oczywiście technicznie rzecz biorąc, nie zrywasz kontraktu… robisz więcej. Więc w pewnym sensie masz rację. Na zakończenie powiedziałbym: „utrudnij jak najbardziej nieporozumienie”.

Myślę, że głównym powodem jest po prostu to, że składnia jest zbyt wyraźna, aby działać w inny sposób. Ten kod:

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

jest dość wyraźne, że zarówno opcje, jak geti setsą nadpisane. W setklasie bazowej nie ma , więc kompilator narzeka. Tak jak nie można przesłonić metody, która nie jest zdefiniowana w klasie bazowej, tak samo nie można przesłonić metody ustawiającej.

Możesz powiedzieć, że kompilator powinien odgadnąć twój zamiar i zastosować nadpisanie tylko do metody, którą można przesłonić (tj. Getter w tym przypadku), ale jest to sprzeczne z jedną z zasad projektowania C # - że kompilator nie może odgadnąć twoich zamiarów , ponieważ może zgadnąć źle bez Twojej wiedzy.

Myślę, że następująca składnia może się nieźle sprawdzić, ale jak powtarza Eric Lippert, wdrożenie nawet niewielkiej funkcji, takiej jak ta, nadal wymaga dużego wysiłku ...

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

lub, w przypadku nieruchomości zaimplementowanych,

public int MyProperty { override get; set; }

Natknąłem się dzisiaj na ten sam problem i myślę, że mam bardzo ważny powód, by tego chcieć.

Najpierw chciałbym argumentować, że posiadanie właściwości tylko do odczytu niekoniecznie przekłada się na tylko do odczytu. Interpretuję to jako „Z tego interfejsu / abstraktu można uzyskać tę wartość”, co nie oznacza, że ​​niektóre implementacje tego interfejsu / klasy abstrakcyjnej nie będą wymagały od użytkownika / programu do jawnego ustawiania tej wartości. Klasy abstrakcyjne służą do realizacji części potrzebnej funkcjonalności. Nie widzę żadnego powodu, dla którego odziedziczona klasa nie mogłaby dodać setera bez naruszania jakichkolwiek umów.

Poniżej znajduje się uproszczony przykład tego, czego potrzebowałem dzisiaj. Skończyło się na tym, że musiałem dodać setera do mojego interfejsu, aby to obejść. Powodem dodania settera i nie dodawania, powiedzmy, metody SetProp jest to, że jedna konkretna implementacja interfejsu wykorzystywała DataContract / DataMember do serializacji Prop, co byłoby niepotrzebnie skomplikowane, gdybym musiał dodać kolejną właściwość tylko w tym celu serializacji.

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

Wiem, że to tylko post „mój za 2 centy”, ale czuję, że w przypadku oryginalnego plakatu próba zracjonalizowania tego, że to dobra rzecz, wydaje mi się dziwna, zwłaszcza biorąc pod uwagę, że te same ograniczenia nie mają zastosowania w przypadku dziedziczenia bezpośrednio po berło.

Również wzmianka o używaniu new zamiast override nie ma tutaj zastosowania, po prostu nie działa, a nawet gdyby tak było, nie dałoby to pożądanego rezultatu, a mianowicie wirtualnego gettera opisanego przez interfejs.

To jest możliwe

tl; dr - Jeśli chcesz, możesz zastąpić metodę ustawiającą tylko metodę pobierania. Po prostu:

1. Utwórz newwłaściwość, która ma zarówno a, jak geti a, setużywając tej samej nazwy.

2. Jeśli nie zrobisz nic innego, stara getmetoda będzie nadal wywoływana, gdy klasa pochodna zostanie wywołana przez jej typ podstawowy. Aby to naprawić, dodaj abstractwarstwę pośrednią, która używa overridestarej getmetody, aby zmusić ją do zwrócenia wyniku nowej getmetody.

To pozwala nam zastąpić właściwości z get/ setnawet jeśli ich brakowało w ich podstawowej definicji.

Jako bonus możesz także zmienić typ zwrotu, jeśli chcesz.

• Jeśli podstawową definicją była get-only, można użyć bardziej pochodnego typu zwracanego.

• Jeśli podstawową definicją było set-only, możesz użyć mniej pochodnego typu zwracanego.

• Jeśli podstawową definicją była już get/ set, to:

  • możesz użyć bardziej pochodnego typu zwracanego, jeśliset ustawisz go -only;

  • możesz użyć mniej pochodnego typu zwracanego, jeśliget ustawisz go -only.

We wszystkich przypadkach możesz zachować ten sam typ zwrotu, jeśli chcesz. Poniższe przykłady używają tego samego typu zwracanego dla uproszczenia.

Sytuacja: istniejąca gettylko własność

Masz strukturę klas, której nie możesz modyfikować. Może to tylko jedna klasa lub jest to wcześniej istniejące drzewo dziedziczenia. W każdym razie chcesz dodać setmetodę do właściwości, ale nie możesz.

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

Problem: Can't overridethe- getonly with get/set

Chcesz overridez właściwością get/ set, ale nie zostanie ona skompilowana.

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

Rozwiązanie: użyj abstractwarstwy pośredniej

Chociaż nie można bezpośrednio overridez get/ setwłasności, to można :

1. Utwórz new get/ setproperty o tej samej nazwie.

2. overridestara getmetoda z akcesorium do nowej getmetody w celu zapewnienia spójności.

Więc najpierw napisz abstractwarstwę pośrednią:

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

Następnie piszesz klasę, która nie skompiluje się wcześniej. Skompiluje się tym razem, ponieważ w rzeczywistości nie jest overrideto getjedyna właściwość; zamiast tego zastępujesz go newsłowem kluczowym.

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

Wynik: wszystko działa!

Oczywiście działa to zgodnie z przeznaczeniem 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.

Wszystko nadal działa zgodnie z przeznaczeniem, gdy jest wyświetlane Djako jedna z jego klas bazowych, np . ALub B. Ale powód, dla którego to działa, może być nieco mniej oczywisty.

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.

Jednak definicja klasy bazowej getjest nadal ostatecznie zastępowana przez definicję klasy pochodnej get, więc nadal jest całkowicie spójna.

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.

Dyskusja

Ta metoda umożliwia dodawanie setmetod gettylko do właściwości. Możesz go również używać do takich rzeczy, jak:

1. Zmień dowolną właściwość na get-only, set-only lub get-and- setproperty, niezależnie od tego, jaka była w klasie bazowej.

2. Zmień zwracany typ metody w klasach pochodnych.

Główną wadą jest to, że jest więcej do zrobienia kodowania i dodatkowy element abstract classw drzewie dziedziczenia. Może to być trochę denerwujące w przypadku konstruktorów, które przyjmują parametry, ponieważ muszą one zostać skopiowane / wklejone w warstwie pośredniej.

Zgadzam się, że brak możliwości przesłonięcia metody pobierającej w typie pochodnym jest anty-wzorcem. Tylko do odczytu oznacza brak implementacji, a nie umowę o czystym funkcjonale (sugerowaną przez najwyższą odpowiedź głosową).

Podejrzewam, że Microsoft miał to ograniczenie albo z powodu promowania tego samego błędnego przekonania, albo może z powodu uproszczenia gramatyki; chociaż teraz ten zakres można zastosować do uzyskania lub ustawienia indywidualnie, być może możemy mieć nadzieję, że nadpisanie też będzie.

Błędne przekonanie wskazywane przez odpowiedź w najwyższym głosowaniu, że właściwość tylko do odczytu powinna być w jakiś sposób bardziej „czysta” niż właściwość do odczytu / zapisu, jest absurdalne. Wystarczy spojrzeć na wiele typowych właściwości tylko do odczytu we frameworku; wartość nie jest stałą / czysto funkcjonalną; na przykład DateTime.Now jest tylko do odczytu, ale nie jest czystą wartością funkcjonalną. Próba „buforowania” wartości właściwości tylko do odczytu przy założeniu, że następnym razem zwróci tę samą wartość, jest ryzykowna.

W każdym razie zastosowałem jedną z następujących strategii, aby pokonać to ograniczenie; oba są mniej niż doskonałe, ale pozwolą ci utykać poza tym brakiem języka:

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

Być może możesz obejść ten problem, tworząc nową właściwość:

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

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

Rozumiem wszystkie twoje uwagi, ale w rzeczywistości automatyczne właściwości C # 3.0 stają się bezużyteczne w tym przypadku.

Nie możesz zrobić czegoś takiego:

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

IMO, C # nie powinno ograniczać takich scenariuszy. Deweloper jest odpowiedzialny za jego odpowiednie użycie.

Problem polega na tym, że z jakiegoś powodu Microsoft zdecydował, że powinny istnieć trzy różne typy właściwości: tylko do odczytu, tylko do zapisu i do odczytu i zapisu, z których tylko jedna może istnieć z daną sygnaturą w danym kontekście; właściwości mogą być zastępowane tylko przez identycznie zadeklarowane właściwości. Aby zrobić to, co chcesz, konieczne byłoby utworzenie dwóch właściwości o tej samej nazwie i podpisie - jedna z nich była tylko do odczytu, a druga do odczytu i zapisu.

Osobiście chciałbym, aby można było znieść całe pojęcie „właściwości”, z wyjątkiem tego, że składnia właściwości mogłaby być używana jako cukier składniowy do wywoływania metod „get” i „set”. Ułatwiłoby to nie tylko opcję „dodaj zestaw”, ale także umożliwiłoby „get” zwrócenie innego typu niż „zestaw”. Chociaż taka zdolność nie byłaby używana zbyt często, czasami może być przydatne, gdyby metoda „get” zwracała obiekt opakowania, podczas gdy „zestaw” mógł akceptować opakowanie lub rzeczywiste dane.

Oto obejście, aby to osiągnąć za pomocą 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);
}

W ten sposób możemy ustawić wartość obiektu dla właściwości, która jest tylko do odczytu. Może jednak nie działać we wszystkich scenariuszach!

Powinieneś zmienić tytuł pytania, aby albo wyszczególnić, że twoje pytanie dotyczy wyłącznie nadpisywania własności abstrakcyjnej, albo że twoje pytanie dotyczy generalnie przesłaniania właściwości klasy tylko do pobierania.

Jeśli pierwszy (przesłaniając abstrakcyjną właściwość)

Ten kod jest bezużyteczny. Sama klasa bazowa nie powinna mówić, że jesteś zmuszony do przesłonięcia właściwości Get-Only (być może interfejs). Klasa bazowa zapewnia typowe funkcje, które mogą wymagać określonych danych wejściowych z klasy implementującej. Dlatego wspólna funkcjonalność może wywoływać abstrakcyjne właściwości lub metody. W danym przypadku typowe metody funkcjonalności powinny prosić Cię o zastąpienie metody abstrakcyjnej, takiej jak:

public int GetBar(){}

Ale jeśli nie masz nad tym kontroli, a funkcjonalność klasy bazowej odczytuje z własnej właściwości publicznej (dziwne), po prostu zrób to:

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

Chcę zwrócić uwagę na (dziwny) komentarz: powiedziałbym, że najlepszą praktyką jest, aby klasa nie używała swoich własnych właściwości publicznych, ale używała swoich prywatnych / chronionych pól, gdy one istnieją. Więc to jest lepszy wzór:

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

Jeśli to drugie (przesłaniając właściwość klasy tylko do pobierania)

Każda nieabstrakcyjna właściwość ma metodę ustawiającą. W przeciwnym razie jest bezużyteczny i nie powinieneś go używać. Microsoft nie musi pozwalać ci robić tego, co chcesz. Powód jest taki: seter istnieje w takiej czy innej formie i możesz łatwo osiągnąć to, co chcesz, Veerryy .

Klasa bazowa lub dowolna klasa, za pomocą której można odczytać właściwość {get;}, ma NIEKTÓRE rodzaje odsłoniętej metody ustawiającej dla tej właściwości. Metadane będą wyglądać następująco:

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

Ale implementacja będzie miała dwa końce spektrum złożoności:

Najmniej złożone:

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

Najbardziej złożone:

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

Chodzi mi o to, że tak czy inaczej wystawiasz rozgrywającego. W twoim przypadku możesz chcieć przesłonić, int Barponieważ nie chcesz, aby klasa bazowa sobie z tym poradziła, nie masz dostępu do przeglądu, jak to obsługuje, lub masz za zadanie wbić jakiś kod naprawdę szybko i niegrzecznie wbrew twojej woli .

W ostatnim i dawnym (wniosek)

Krótko mówiąc: Microsoft nie musi niczego zmieniać. Możesz wybrać sposób konfiguracji klasy implementującej i, bez konstruktora, użyć wszystkich lub żadnej klasy bazowej.

Rozwiązanie tylko dla niewielkiego podzbioru przypadków użycia, niemniej jednak: w C # 6.0 metoda ustawiająca „tylko do odczytu” jest dodawana automatycznie dla przesłoniętych właściwości tylko pobierających.

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

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

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

Ponieważ to złamałoby koncepcję hermetyzacji i ukrywania implementacji. Rozważ przypadek, kiedy tworzysz klasę, wysyłasz ją, a następnie konsument Twojej klasy może ustawić właściwość, dla której pierwotnie zapewniłeś tylko metodę pobierającą. Skutecznie zakłóciłoby to wszystkie niezmienniki twojej klasy, na których możesz polegać w swojej implementacji.

To nie jest niemożliwe. Musisz po prostu użyć słowa kluczowego „nowe” w swojej usłudze. Na przykład,

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

Wydaje się, że takie podejście zadowala obie strony tej dyskusji. Użycie „nowego” powoduje zerwanie kontraktu między implementacją klasy bazowej a implementacją podklasy. Jest to konieczne, gdy klasa może mieć wiele kontraktów (za pośrednictwem interfejsu lub klasy bazowej).

Mam nadzieję że to pomoże

Właściwość tylko do odczytu w klasie bazowej wskazuje, że ta właściwość reprezentuje wartość, którą zawsze można określić z poziomu klasy (na przykład wartość wyliczenia pasująca do kontekstu (db-) obiektu). Zatem odpowiedzialność za określenie wartości pozostaje w obrębie klasy.

Dodanie metody ustawiającej spowodowałoby tutaj niezręczny problem: błąd walidacji powinien wystąpić, jeśli ustawisz wartość na cokolwiek innego niż pojedyncza możliwa wartość, którą już ma.

Jednak reguły często mają wyjątki. Jest bardzo możliwe, że na przykład w jednej klasie pochodnej kontekst zawęża możliwe wartości wyliczenia do 3 z 10, ale użytkownik tego obiektu nadal musi zdecydować, który z nich jest poprawny. Klasa pochodna musi delegować odpowiedzialność za określenie wartości na użytkownika tego obiektu. Ważne jest, aby zdać sobie sprawę, że użytkownik tego obiektu powinien być dobrze świadomy tego wyjątku i przyjąć na siebie odpowiedzialność za ustawienie prawidłowej wartości.

Moim rozwiązaniem w tego rodzaju sytuacjach byłoby pozostawienie właściwości tylko do odczytu i dodanie nowej właściwości do odczytu i zapisu do klasy pochodnej w celu obsługi wyjątku. Przesłonięcie oryginalnej właściwości po prostu zwróci wartość nowej właściwości. Nowa właściwość może mieć własną nazwę wskazującą poprawnie kontekst tego wyjątku.

Potwierdza to również słuszną uwagę: „utrudnij jak najbardziej nieporozumienia” Gishu.

Ponieważ na poziomie IL właściwość odczytu / zapisu przekłada się na dwie metody (pobierającą i ustawiającą).

Podczas zastępowania musisz nadal wspierać podstawowy interfejs. Gdybyś mógł dodać ustawiającego, w rzeczywistości dodawałbyś nową metodę, która pozostałaby niewidoczna dla świata zewnętrznego, jeśli chodzi o interfejs twoich klas.

To prawda, że ​​dodanie nowej metody nie naruszyłoby kompatybilności jako takiej, ale ponieważ pozostałaby ona ukryta, decyzja o jej odrzuceniu ma sens.

Ponieważ klasa, która ma właściwość tylko do odczytu (bez metody ustawiającej), prawdopodobnie ma ku temu dobry powód. Na przykład może nie być żadnego bazowego magazynu danych. Umożliwienie stworzenia setera łamie kontrakt przedstawiony przez klasę. To po prostu złe OOP.