Il nuovo operatore null-condizionale di C # 6.0 va contro la Legge di Demetra?

La legge di Demetra afferma quanto segue:

• Ogni unità dovrebbe avere una conoscenza limitata delle altre unità: solo le unità "strettamente" correlate all'unità corrente.
• Ogni unità dovrebbe parlare solo con i suoi amici; non parlare con estranei.
• Parla solo con i tuoi amici immediati.

C # 6.0 ha introdotto un nuovo operatore chiamato operatore null-condizionale . IMHO, semplifica la codifica e migliora la leggibilità. Ma semplifica anche la scrittura di più codice accoppiato, poiché è più semplice navigare nei campi di classe, verificando già la nullità (qualcosa del genere var x = A?.B?.C?.D?.E?.F?).

È corretto affermare che questo nuovo operatore è contrario alla Legge di Demetra?

È corretto affermare che questo nuovo operatore è contrario alla Legge di Demetra?

No ^*

^* L'operatore condizionale null è uno strumento all'interno del linguaggio e del framework .NET. Qualsiasi strumento ha la capacità di essere abusato e utilizzato in modi che potrebbero danneggiare la manutenibilità di una determinata applicazione.

Ma il fatto che uno strumento possa essere abusato non significa necessariamente che debba essere abusato, né che lo strumento violi determinati principi che possono essere sostenuti.

La Legge di Demetra e altri sono linee guida su come dovresti scrivere il tuo codice. È mirato agli umani, non agli strumenti. Quindi il fatto che il linguaggio C # 6.0 abbia un nuovo strumento al suo interno non influenza necessariamente il modo in cui dovresti scrivere e strutturare il tuo codice.

Con qualsiasi nuovo strumento, è necessario valutare come ... se il ragazzo che finisce per mantenere il vostro codice sarà uno psicopatico violento ... . Nota di nuovo che questa è una guida per la persona che scrive il codice e non sugli strumenti utilizzati.

Una specie di.

Se stai effettuando un solo accesso ( a?.Foo), equivale a:

a == null ? null : a.Foo

che la maggior parte delle persone concorderebbe non è una violazione della Legge di Demetra. A quel punto, è solo zucchero sintattico a migliorare la leggibilità.

Nulla di più di questo, e probabilmente violerebbe la Legge di Demetra, e questa caratteristica tende a promuovere quel tipo di utilizzo. Direi anche che il solo "buon" utilizzo da solo non è sufficiente a giustificare questo tipo di modifica della lingua, quindi mi aspetto che sia stato realizzato per supportare un uso meno chiaramente buono.

Detto questo, vale la pena ricordare che la Legge di Demetra non è una legge in sé, ma più una linea guida. Un sacco di codice lo viola e funziona bene. A volte la semplicità del design o del codice vale più del rischio rappresentato dalla violazione della Legge di Demetra.

No. Consideriamo sia l'operatore da solo, sia l'uso pesantemente incatenato che hai per esso.

Da solo .?Adipende dalla stessa quantità di conoscenza della classe del valore di sinistra e del tipo restituito dal metodo .A != null, vale a dire, vale a dire. Deve sapere che la Aproprietà esiste e restituisce un valore che può essere confrontato null.

Possiamo solo sostenere che ciò viola la legge di Demetra se le proprietà digitate lo fanno. Non siamo nemmeno costretti ad avere Acome tipo concreto (il suo valore potrebbe essere di tipo derivato). L'accoppiamento qui è minimo.

Adesso consideriamo var x = A?.B?.C?.D?.E?.F.

Il che significa che Adeve essere di un tipo che potrebbe essere nullo o potrebbe avere una Bproprietà, che deve essere di un tipo che potrebbe essere nullo o avere una Cproprietà, e così via fino a quando il tipo di Eproprietà è qualcosa che potrebbe essere nullo o potrebbe avere una Fproprietà.

In altre parole, dobbiamo farlo con una lingua tipizzata staticamente o aver applicato un vincolo sui tipi che possono essere restituiti se la digitazione è libera. C # nella maggior parte dei casi usa la tipizzazione statica, quindi non abbiamo cambiato nulla.

Se avessimo quindi il seguente codice violerebbe anche la legge:

ExplicitType x;
var b = A.B;
if (b == null)
  x = null;
else
{
  var c = b.C;
  if (c == null)
    x = null;
  else
  {
    var d = c.D;
    if (d == null)
      x = null;
    else
    {
      var e = d.E;
      if (e == null)
        x = null;
      else
        x = e.F;
    }
  }
}

Che è esattamente lo stesso . Questo codice che utilizza l'accoppiamento di diversi elementi deve "conoscere" l'intera catena di accoppiamento, ma utilizza un codice che non viola la Legge di Demetra per farlo, con ogni unità che ha un accoppiamento ben definito con il prossimo.

L'oggetto può essere creato allo scopo di incapsulare comportamenti o conservare dati, e gli oggetti possono essere creati allo scopo di essere condivisi con codice esterno o tenuti in privato dal loro creatore.

Gli oggetti creati allo scopo di incapsulare comportamenti (condivisi o meno) o per essere condivisi con codice esterno (sia che incapsulino comportamenti o dati) dovrebbero essere generalmente accessibili attraverso la loro interfaccia di superficie. Quando gli oggetti che contengono dati vengono creati per essere utilizzati esclusivamente dal loro creatore, tuttavia, non si applicano le normali ragioni della Legge della Demetra per evitare l'accesso "profondo". Se parte di una classe che archivia o manipola i dati nell'oggetto viene modificata in un modo che richiederebbe la regolazione di altro codice, sarà possibile garantire che tutto tale codice venga aggiornato perché - come notato sopra - l'oggetto è stato creato per l'uso esclusivo di una classe.

Mentre penso al? l'operatore avrebbe potuto essere progettato meglio, ci sono abbastanza situazioni in cui gli oggetti fanno uso di strutture di dati nidificati che l'operatore ha molti casi d'uso che non violerebbero i principi espressi dalla Legge di Demetra. Il fatto che possa essere utilizzato per violare il LoD non dovrebbe essere considerato un argomento contro l'operatore, poiché non è peggio del "." operatore al riguardo.