I wrapper devono comparare come uguali usando l'operatore == quando avvolgono lo stesso oggetto?

Sto scrivendo un wrapper per elementi XML che consente a uno sviluppatore di analizzare facilmente gli attributi dall'XML. Il wrapper non ha altro stato se non l'oggetto da avvolgere.

Sto prendendo in considerazione la seguente implementazione (semplificata per questo esempio) che include un sovraccarico per l' ==operatore.

class XmlWrapper
{
    protected readonly XElement _element;

    public XmlWrapper(XElement element)
    {
        _element = element;
    }

    public string NameAttribute
    {
        get
        {
            //Get the value of the name attribute
        }
        set
        {
            //Set the value of the name attribute
        }
    }

    public override bool Equals(object other)
    {
        var o = other as XmlWrapper;
        if (o == null) return false;
        return _element.Equals(o._element);
    }

    public override int GetHashCode()
    {
        return _element.GetHashCode();
    }

    static public bool operator == (XmlWrapper lhs, XmlWrapper rhs)
    {
        if (ReferenceEquals(lhs, null) && ReferenceEquals(rhs, null)) return true;
        if (ReferenceEquals(lhs, null) || ReferenceEquals(rhs, null)) return false;

        return lhs._element == rhs._element;
    }

    static public bool operator != (XmlWrapper lhs, XmlWrapper rhs)
    {
        return !(lhs == rhs);
    }
}

Come ho capito idiomatico c #, l' ==operatore è per l'uguaglianza di riferimento mentre il Equals()metodo è per l'uguaglianza di valore. Ma in questo caso, il "valore" è solo un riferimento all'oggetto che viene spostato. Quindi non sono chiaro cosa sia convenzionale o idiomatico per c #.

Ad esempio, in questo codice ...

var underlyingElement = new XElement("Foo");
var a = new XmlWrapper(underlyingElement);
var b = new XmlWrapper(underlyingElement);

a.NameAttribute = "Hello";
b.NameAttribute = "World";

if (a == b)
{
    Console.WriteLine("The wrappers a and b are the same.");
}

.... dovrebbe apparire il programma "I wrapper aeb sono uguali"? O sarebbe strano, vale a dire violare il principio del minimo stupore ?

Poiché il riferimento all'involucro XElementè immutabile, non vi è alcuna differenza osservabile esternamente tra due istanze di XmlWrapperquell'involucro dello stesso elemento, quindi ha senso sovraccaricare ==per riflettere questo fatto.

Il codice client si preoccupa quasi sempre dell'uguaglianza logica (che, per impostazione predefinita, viene implementata usando l'uguaglianza di riferimento per i tipi di riferimento). Il fatto che ci siano due istanze nell'heap è un dettaglio di implementazione di cui i clienti non dovrebbero preoccuparsi (e quelli che lo useranno Object.ReferenceEqualsdirettamente).

Se pensi che abbia più senso

La domanda e la risposta sono una questione di aspettative degli sviluppatori , questo non è un requisito tecnico.

Se ritieni che un wrapper non abbia un'identità e che sia definita esclusivamente dal suo contenuto, la risposta alla tua domanda è sì.

Ma questo è un problema ricorrente. Due wrapper dovrebbero mostrare uguaglianza quando avvolgono oggetti diversi ma con entrambi gli oggetti che hanno lo stesso identico contenuto?

La risposta si ripete. SE gli oggetti contenuto non hanno identità personale e invece sono puramente definiti dal loro contenuto, gli oggetti contenuto sono effettivamente wrapper che mostreranno uguaglianza. Se poi avvolgi gli oggetti contenuto in un altro wrapper, anche quel wrapper (aggiuntivo) dovrebbe mostrare uguaglianza.

Sono le tartarughe fino in fondo .

Consiglio generale

Ogni volta che si discosta dal comportamento predefinito, dovrebbe essere esplicitamente documentato. Come sviluppatore, mi aspetto che due tipi di riferimento non mostrino uguaglianza anche se i loro contenuti sono uguali. Se modifichi quel comportamento, ti suggerirei di documentarlo chiaramente in modo che tutti gli sviluppatori siano consapevoli di questo comportamento atipico.

Come ho capito idiomatico c #, l' ==operatore è per l'uguaglianza di riferimento mentre il Equals()metodo è per l'uguaglianza di valore.

Questo è il comportamento predefinito, ma questa non è una regola immobile. È una questione di convenzione, ma le convenzioni possono essere modificate ove giustificabile .

stringè un ottimo esempio qui, così come lo ==è anche un controllo di uguaglianza di valore (anche quando non c'è interning di stringhe!). Perché? In parole povere: perché avere stringhe si comporta come oggetti di valore sembra più intuitivo per la maggior parte degli sviluppatori.

Se la tua base di codice (o la vita dei tuoi sviluppatori) può essere notevolmente semplificata facendo in modo che i tuoi wrapper mostrino uguaglianza di valore su tutta la linea, provaci (ma documentalo ).

Se non hai mai bisogno di controlli di uguaglianza di riferimento (o sono resi inutili dal tuo dominio aziendale), non ha senso mantenere un controllo di uguaglianza di riferimento. È meglio quindi sostituirlo con un controllo di uguaglianza di valore in modo da prevenire errori dello sviluppatore .
Tuttavia, ti rendi conto che se avessi bisogno di controlli di uguaglianza di riferimento in un secondo momento, la reimplementazione potrebbe richiedere uno sforzo notevole.

Stai fondamentalmente confrontando le stringhe, quindi sarei stupito se due wrapper con lo stesso contenuto XML non fossero considerati uguali, sia esso verificato usando Equals o ==.

La regola idiomatica può avere senso per gli oggetti del tipo di riferimento in generale, ma le stringhe sono speciali in un senso idiomatico, dovresti trattarle e considerarle come valori sebbene tecnicamente siano tipi di riferimento.

Il postfix del tuo wrapper aggiunge però confusione. In pratica dice "non un elemento XML". Quindi dovrei trattarlo come un tipo di riferimento dopo tutto? Semanticamente questo non avrebbe senso. Sarei meno confuso se la classe fosse chiamata XmlContent. Questo significherebbe che ci preoccupiamo dei contenuti, non dei dettagli tecnici di implementazione.