Il mio utilizzo dell'operatore di casting esplicito è ragionevole o è un trucco dannoso?

Ho un grande oggetto:

class BigObject{
    public int Id {get;set;}
    public string FieldA {get;set;}
    // ...
    public string FieldZ {get;set;}
}

e un oggetto specializzato, simile a DTO:

class SmallObject{
    public int Id {get;set;}
    public EnumType Type {get;set;}
    public string FieldC {get;set;}
    public string FieldN {get;set;}
}

Personalmente trovo un concetto di trasmissione esplicita di BigObject in SmallObject - sapendo che si tratta di un'operazione a senso unico, che perde dati - molto intuitiva e leggibile:

var small = (SmallObject) bigOne;
passSmallObjectToSomeone(small);

È implementato usando l'operatore esplicito:

public static explicit operator SmallObject(BigObject big){
    return new SmallObject{
        Id = big.Id,
        FieldC = big.FieldC,
        FieldN = big.FieldN,
        EnumType = MyEnum.BigObjectSpecific
    };
}

Ora, potrei creare una SmallObjectFactoryclasse con FromBigObject(BigObject big)metodo, che farebbe la stessa cosa, aggiungerla all'iniezione di dipendenza e chiamarla quando necessario ... ma a me sembra ancora più complicata e inutile.

PS Non sono sicuro che questo sia pertinente, ma ci OtherBigObjectsarà anche la possibilità di essere convertito in SmallObject, impostazione diversa EnumType.

Nessuna delle altre risposte ha ragione a mio modesto parere. In questa domanda stackover la risposta più votata sostiene che il codice di mappatura dovrebbe essere tenuto fuori dal dominio. Per rispondere alla tua domanda, no: il tuo utilizzo dell'operatore cast non è eccezionale. Ti consiglierei di creare un servizio di mappatura che si trova tra il tuo DTO e l'oggetto del tuo dominio, o potresti usare automapper per questo.

È ... Non eccezionale. Ho lavorato con il codice che ha fatto questo trucco intelligente e ha portato alla confusione. Dopotutto, ti aspetteresti di essere in grado di assegnare BigObjectin una SmallObjectvariabile solo se gli oggetti sono abbastanza correlati da lanciarli. Tuttavia, non funziona: si verificano errori del compilatore se si tenta dal momento che per quanto riguarda il sistema di tipi, non sono correlati. È anche leggermente sgradevole per l'operatore del casting creare nuovi oggetti.

Consiglierei .ToSmallObject()invece un metodo. È più chiaro su ciò che sta realmente accadendo e su come dettagliato.

Mentre vedo perché dovresti averne uno SmallObject, affronterei il problema in modo diverso. Il mio approccio a questo tipo di problema consiste nell'utilizzare una facciata . Il suo unico scopo è incapsulare BigObjecte rendere disponibili solo membri specifici. In questo modo, si tratta di una nuova interfaccia sulla stessa istanza e non di una copia. Naturalmente potresti anche voler eseguire una copia, ma ti consiglio di farlo attraverso un metodo creato a tale scopo in combinazione con la facciata (ad esempio return new SmallObject(instance.Clone())).

La facciata presenta una serie di altri vantaggi, vale a dire garantire che determinate sezioni del programma possano fare uso solo dei membri resi disponibili attraverso la facciata, garantendo in modo efficace che non possa fare uso di ciò che non dovrebbe sapere. Oltre a questo, ha anche l'enorme vantaggio di avere una maggiore flessibilità nel cambiare la BigObjectmanutenzione futura senza doversi preoccupare troppo di come viene utilizzato durante il programma. Finché puoi emulare il vecchio comportamento in un modo o nell'altro, puoi fare il SmallObjectlavoro come prima senza dover cambiare il tuo programma ovunque BigObjectsarebbe stato usato.

Nota, questo significa BigObjectche non dipende, SmallObjectma piuttosto il contrario (come dovrebbe essere secondo la mia modesta opinione).

Esiste una convenzione molto forte che lancia su tipi di riferimento mutabili che preservano l'identità. Poiché il sistema generalmente non consente agli operatori di casting definiti dall'utente in situazioni in cui un oggetto del tipo di origine potrebbe essere assegnato a un riferimento del tipo di destinazione, ci sono solo pochi casi in cui le operazioni di casting definite dall'utente sarebbero ragionevoli per riferimento mutabile tipi.

Vorrei suggerire come requisito che, dato x=(SomeType)foo;seguito qualche tempo dopo y=(SomeType)foo;, con entrambi i cast applicati allo stesso oggetto, x.Equals(y)dovrebbe essere sempre e per sempre vero, anche se l'oggetto in questione è stato modificato tra i due cast. Una situazione del genere potrebbe applicarsi se, ad esempio, uno avesse una coppia di oggetti di tipi diversi, ognuno dei quali conteneva un riferimento immutabile all'altro, e il lancio di uno o l'altro oggetto sull'altro tipo restituirebbe la sua istanza accoppiata. Potrebbe anche applicarsi con tipi che fungono da involucri per oggetti mutabili, a condizione che le identità degli oggetti da avvolgere fossero immutabili e che due involucri dello stesso tipo si dichiarassero uguali se avessero avvolto la stessa raccolta.

Il tuo esempio particolare usa classi mutabili, ma non conserva alcuna forma di identità; come tale, suggerirei che non è un uso appropriato di un operatore di casting.

Potrebbe andare bene.

Un problema con il tuo esempio è che usi questi nomi di esempio. Ritenere:

SomeMethod(long longNum)
{
  int num = (int)longNum;
  /* ... */

Ora, quando hai una buona idea di cosa significhi un lungo e un int , allora sia il cast implicito di intto longche il cast esplicito da longto intsono abbastanza comprensibili. È anche comprensibile come 3diventa 3ed è solo un altro modo di lavorare 3. È comprensibile come ciò fallirà int.MaxValue + 1in un contesto controllato. Anche il modo in cui funzionerà int.MaxValue + 1in un contesto non controllato per ottenere int.MinValuenon è la cosa più difficile da capire.

Allo stesso modo, quando si esegue il cast implicitamente su un tipo di base o esplicitamente su un tipo derivato, è comprensibile a chiunque sappia come l'ereditarietà funzioni ciò che sta accadendo e quale sarà il risultato (o come potrebbe non riuscire).

Ora, con BigObject e SmallObject non ho idea di come funzioni questa relazione. Se i tuoi tipi reali erano tali che la relazione sul casting fosse ovvia, allora il casting potrebbe davvero essere una buona idea, anche se il più delle volte, forse la stragrande maggioranza, se questo è il caso, allora dovrebbe riflettersi nella gerarchia di classi e nel sarà sufficiente la normale fusione basata sull'eredità.