readonly-fields come target dai costruttori di sottoclasse

Question

Un campo di sola lettura deve essere utilizzato quando si dispone di una variabile che sarà nota all'oggetto-instatiation che non dovrebbe essere modificata in seguito.

Tuttavia non è consentito assegnare campi di sola lettura da costruttori di sottoclassi. Questo non funziona nemmeno se la superclasse è astratta.

Qualcuno ha una buona spiegazione del perché questa non è una buona idea, o manca nella C# languange?

abstract class Super 
{ 
    protected readonly int Field; 
} 

class Sub : Super 
{ 
    public Sub() 
    { 
     this.Field = 5; //Not compileable 
    } 
} 

PS: Ovviamente si può raggiungere lo stesso risultato con l'assegnazione dei campi di sola lettura in un costruttore protetto nella superclasse.

Answer 1

L'unico motivo che posso vedere per questo è perché "è stato appena concepito in questo modo", come per i spec:

incarichi diretti a sola lettura campi possono avvenire solo come parte di tale dichiarazione o in un costruttore di istanze o un costruttore statico nella stessa classe .

Il punto di essere sola lettura è che non può essere modificata, se classi derivate potrebbe modificare allora questo non sarebbe più vero e violare l'incapsulamento (modificando la struttura interna di un'altra classe).

Answer 2

public class Father 
{ 
    protected readonly Int32 field; 

    protected Father (Int32 field) 
    { 
     this.field = field; 
    } 
} 

public class Son : Father 
{ 
    public Son() : base(5) 
    { 

    } 
} 

Si può provare qualcosa di simile, invece!

Answer 3

suppongo che il motivo principale è una complessità aggiuntiva per tutte le implementazioni .NET lingua

anche, c'è sempre una soluzione semplice:

abstract class Super 
{ 
    protected readonly int Field; 

    protected Super(int field) 
    { 
      this.Field = field; 
    } 
} 


class Sub : Super { 
    public Sub():base(5) 
    { 
    } 

}

Answer 4

avrei modellare questo da un proprietà astratta/virtuale in C#.

Secondo me è una soluzione migliore rispetto a un costruttore che include ogni singolo campo di sola lettura come parametro Per uno perché il compilatore è in grado di inline questo come bene e anche perché la soluzione costruttore avrà questo aspetto nella classe derivata:

class Sub : Super { 
    public Sub() : base(5) { } // 5 what ?? -> need to check definition of super class constructor 
} 

inoltre che potrebbe non funzionare se si dispone già di un costruttore che prende un singolo int valore.

Answer 5

Preferirei utilizzare il costruttore protetto in superclasse (come menzionato da alexm), a portata di mano con commenti xml. Questo dovrebbe eliminare il problema che ha detto DonAndre nel suo commento sul codice.