Devo restituire true in un metodo che lancia null da un tipo di oggetto a un altro?

1

Sto scrivendo un metodo di estensione molto semplice che tenta di trasmettere oggetti da un tipo all'altro. L'intento di avere questo metodo è molto simile a Int32.TryParse(string, out int) , che consente all'utente di vedere 1) se la conversione è riuscita, e 2) che cos'è l'oggetto convertito, tutto in una riga.

Poiché questo metodo si occuperà esclusivamente di oggetti classe, è possibile che l'oggetto da cast sia effettivamente nullo. Null può essere lanciato su qualsiasi tipo annullabile (almeno questo è quello che sembra basato sui miei test), quindi tecnicamente il metodo avrebbe sempre avuto successo in quella situazione. D'altra parte, provare a convertire null non ha un grande scopo e di solito è un segno di cose che sono andate storte. Pertanto, la mia domanda è: nel caso in cui l'oggetto fornito sia nullo, dovrei restituire true (il cast è riuscito) o falso (non è riuscito)?

Questo è (più o meno) il metodo in questione:

public static bool TryGetAs<T>(this object obj, out T output) where T : class
{
    output = null;
    if (obj == null)
        return [true or false];

    output = obj as T;
    return output != null;
}
    
posta Mage Xy 05.12.2016 - 22:48
fonte

2 risposte

3

Guarda cosa vogliono i tuoi clienti e prova a fornire un'astrazione che sia utile. E se sei il tuo cliente, prova a pensare in modo critico a ciò che vuoi come cliente piuttosto che come implementatore.

Direi che al punto che qualcuno chiama questo, ora sono interessati solo se l'elemento fornisce l'API del tipo (che null non lo fa).

Se restituisci true per null, i tuoi clienti sono IMNSHO molto probabile che debbano fare il proprio controllo nullo insieme a, e prima o dopo aver usato, il tuo metodo. Solo in rari casi diversi non avranno bisogno del loro controllo nullo.

Se restituisci false, non dovranno effettuare il controllo null.

Ancora, dai un'occhiata a come i clienti usano la funzione e avrai la tua risposta.

    
risposta data 05.12.2016 - 23:06
fonte
1

Se il tuo parametro di input è null, non sei in grado di decidere quale sia il giusto valore di ritorno. Qualsiasi valore di ritorno sarebbe buono come l'altro. Non importa se è null, true, false o "foobar".

Ottenere un tipo speciale di oggetto da un oggetto arbitrario è davvero faticoso. Dubito davvero del caso. Il punto è che il tuo metodo generico usa una risoluzione specifica del linguaggio che funziona solo con tipi correlati ... o almeno ha senso solo con i tipi correlati ...

La differenza tra il metodo e il metodo di analisi è: il metodo int parse fornisce un algoritmo concreto per risolvere il numero intero da una stringa. Questo algoritmo è semanticamente ben definito.

Il tuo algoritmo può essere tecnicamente ben definito ma non semanticamente. Puoi facilmente vedere che se provi a inserire un oggetto di un tuo tipo personalizzato e vuoi restituire una stringa. Non riesco a immaginare come possa aver senso. Come può questo metodo fare meglio di un metodo toString sull'oggetto sorgente stesso? L'algoritmo fornito non ha semantica.

Quindi se rendi il metodo generico e il tuo algoritmo ha senso solo per gli input SOME e gli output SOME, perché dovrei confondere gli utenti di questo metodo facendo finta che stia facendo cose utili?

Evita questo tipo di metodi che fingono generici ma che non lo sono.

    
risposta data 05.12.2016 - 23:30
fonte

Leggi altre domande sui tag