Quali sono alcuni usi pratici del "nuovo" modificatore in C # rispetto al nascondersi?

Un collega e io stavamo esaminando il comportamento della newparola chiave in C # in quanto si applica al concetto di nascondersi. Dalla documentazione :

Utilizzare il nuovo modificatore per nascondere esplicitamente un membro ereditato da una classe base. Per nascondere un membro ereditato, dichiararlo nella classe derivata usando lo stesso nome e modificarlo con il nuovo modificatore.

Abbiamo letto la documentazione e capiamo cosa fa sostanzialmente e come lo fa. Ciò su cui non siamo riusciti a capire è perché dovresti farlo in primo luogo. Il modificatore è stato lì dal 2003, e abbiamo entrambi lavorato con .Net per un periodo più lungo di quello e non è mai arrivato.

Quando questo comportamento sarebbe necessario in senso pratico (ad es. Come applicato a un caso aziendale)? È questa una caratteristica che è sopravvissuta alla sua utilità o è ciò che fa semplicemente abbastanza inusuale in quello che facciamo (in particolare facciamo moduli web e applicazioni MVC e alcuni WinForms e WPF a fattore ridotto)? Nel provare questa parola chiave e giocarci abbiamo trovato alcuni comportamenti che permettono che sembrino un po 'pericolosi se usati in modo improprio.

Sembra un po 'aperto, ma stiamo cercando un caso d'uso specifico che può essere applicato a un'applicazione aziendale che trova utile questo particolare strumento.

Puoi usarlo per imitare la covarianza del tipo di ritorno. Spiegazione di Eric Lippert . Eric fornisce questo codice di esempio:

abstract class Enclosure
{
    protected abstract Animal GetContents();
    public Animal Contents() { return this.GetContents(); }
}
class Aquarium : Enclosure
{
    public new Fish Contents() { ... }
    protected override Animal GetContents() { return this.Contents(); }
}

Questa è una soluzione. public override Fish Contents() { ... }non è legale, nonostante sia sicuro.

In generale, è consigliabile non utilizzare il metodo nascosto, in quanto è fonte di confusione per i consumatori della classe (l'esempio specifico di cui sopra non soffrono di questo problema). Basta nominare il nuovo metodo in modo diverso se non si desidera sovrascrivere un metodo esistente.

Una probabile situazione del mondo reale in cui occorrerebbe nascondere il metodo è se il provider di una classe base ha aggiunto un metodo generico che era già stato aggiunto a una classe derivata. Un programma del genere compilerà (e fornirà avvisi) senza la nuova parola chiave, ma l'aggiunta newdice: "So che la mia versione di questo metodo sta sostituendo la versione della classe base. Questo è orribile e confuso, ma ne siamo bloccati". È ancora meglio che forzare la classe derivata a rinominare il loro metodo.

Il solo fatto di considerare il metodo derivato come una sostituzione provocherebbe problemi. Ignorando qualsiasi preoccupazione con l'implementazione del compilatore, il nuovo metodo è semanticamente diverso dal metodo di base, ma il polimorfismo farebbe chiamare il nuovo metodo quando viene chiesto di chiamare un metodo con lo stesso nome.

Questa situazione è discussa in dettaglio in questo post di Eric Lippert.

Penso che sia lì nel caso in cui potresti averne bisogno per fare qualcosa a cui i progettisti del linguaggio potrebbero non aver pensato. C # è stato per molti versi una reazione alle prime versioni di Java. E una cosa che java ha fatto è stata quella di picchiare esplicitamente gli sviluppatori per eliminare le possibilità che gli sviluppatori si sparassero ai piedi. C # ha adottato un approccio leggermente diverso e ha dato agli sviluppatori un po 'più di potenza nel consentire agli sviluppatori qualche opportunità in più per spararsi ai piedi. Un esempio è la unsafeparola chiave. Questa newparola chiave è un'altra.

Ora, probabilmente non è così utile come, unsafema una volta entrati in una specifica di lingua è difficile uscire da una specifica di lingua.

Sta dicendo al lettore che "Ho deliberatamente nascosto l'implementazione di questo metodo della classe base", al contrario di accidentalmente.

È possibile che si desideri che il membro precedente sia disponibile tramite l'altro nome:

class VehicleClass
{
  public int AnyProperty
  {
    get; set;
  }

  public int AnyFunction() { return 0; }
} // VehicleClass

class IntermediateClass : VehicleClass
{
  public int PreviousAnyProperty
  {
    get { return AnyProperty; }
    set { AnyProperty = value  }
  }

  public int PreviousAnyFunction() { return AnyFunction(); }
} // IntermediateClass 

class CarClass : IntermediateClass
{
  public new int AnyProperty
  {
    get ; set ;
  }

  public new int AnyFunction() { return 5; }
} // class CarClass

class ExampleClass
{

  public static void Main()
  {
    using (CarClass MyCar = new CarClass())
    {
      int AnyInt1 = MyCar.PreviousAnyProperty;
      MyCar.PreviousAnyProperty = 7;

      int AnyInt2 = MyCar.PreviousAnyFunction();

      int AnyInt3 = MyCar.AnyProperty;
      MyCar.AnyProperty = 45;

      int AnyInt4 = MyCar.AnyFunction();
    }
  } // static void Main()

} // class CarClass

Saluti.

L'ho trovato abbastanza utile durante la creazione di una suite di test per il codice legacy. Mi permette di nascondere dipendenze esterne, come interrogare un database all'interno di un metodo utilizzato da altri metodi. Per poter testare gli altri metodi, posso nascondere la logica originale che dipende da risorse esterne senza la necessità di aggiungere la parola chiave virtuale a tali metodi nelle classi di test.