Chiamata al metodo se non null in C #

È possibile in qualche modo abbreviare questa affermazione?

if (obj != null)
    obj.SomeMethod();

perché lo scrivo molto spesso e diventa piuttosto fastidioso. L'unica cosa a cui riesco a pensare è implementare il pattern Null Object , ma non è quello che posso fare ogni volta e certamente non è una soluzione per abbreviare la sintassi.

E un problema simile con gli eventi, dove

public event Func<string> MyEvent;

e quindi invocare

if (MyEvent != null)
    MyEvent.Invoke();

Da C # 6 in poi, puoi semplicemente usare:

MyEvent?.Invoke();

o:

obj?.SomeMethod();

Il ?.è l'operatore null-moltiplicazione, e causano la .Invoke()di essere cortocircuitato quando l'operando è null. L'operando è accessibile solo una volta, quindi non c'è il rischio del problema di "cambio di valore tra check e invoke".

===

Prima di C # 6, no: non esiste alcuna magia null-safe, con un'eccezione; metodi di estensione, ad esempio:

public static void SafeInvoke(this Action action) {
    if(action != null) action();
}

ora questo è valido:

Action act = null;
act.SafeInvoke(); // does nothing
act = delegate {Console.WriteLine("hi");}
act.SafeInvoke(); // writes "hi"

In caso di eventi, questo ha il vantaggio di rimuovere anche la race condition, ovvero non serve una variabile temporanea. Quindi normalmente avresti bisogno di:

var handler = SomeEvent;
if(handler != null) handler(this, EventArgs.Empty);

ma con:

public static void SafeInvoke(this EventHandler handler, object sender) {
    if(handler != null) handler(sender, EventArgs.Empty);
}

possiamo usare semplicemente:

SomeEvent.SafeInvoke(this); // no race condition, no null risk

Quello che stai cercando è il Null condizionale (non "coalescenza") Operatore: ?.. È disponibile a partire da C # 6.

Il tuo esempio sarebbe obj?.SomeMethod();. Se obj è nullo, non accade nulla. Quando il metodo ha argomenti, ad esempio obj?.SomeMethod(new Foo(), GetBar());gli argomenti non vengono valutati se objè nullo, che importa se la valutazione degli argomenti avrebbe effetti collaterali.

E il concatenamento è possibile: myObject?.Items?[0]?.DoSomething()

Un metodo di estensione rapido:

    public static void IfNotNull<T>(this T obj, Action<T> action, Action actionIfNull = null) where T : class {
        if(obj != null) {
            action(obj);
        } else if ( actionIfNull != null ) {
            actionIfNull();
        }
    }

esempio:

  string str = null;
  str.IfNotNull(s => Console.Write(s.Length));
  str.IfNotNull(s => Console.Write(s.Length), () => Console.Write("null"));

o in alternativa:

    public static TR IfNotNull<T, TR>(this T obj, Func<T, TR> func, Func<TR> ifNull = null) where T : class {
        return obj != null ? func(obj) : (ifNull != null ? ifNull() : default(TR));
    }

esempio:

    string str = null;
    Console.Write(str.IfNotNull(s => s.Length.ToString());
    Console.Write(str.IfNotNull(s => s.Length.ToString(), () =>  "null"));

Gli eventi possono essere inizializzati con un delegato predefinito vuoto che non viene mai rimosso:

public event EventHandler MyEvent = delegate { };

Nessun controllo null necessario.

[ Aggiornamento , grazie a Bevan per averlo segnalato]

Sii consapevole del possibile impatto sulle prestazioni, però. Un rapido micro benchmark che ho fatto indica che la gestione di un evento senza sottoscrittori è 2-3 volte più lenta quando si utilizza il pattern "delegato predefinito". (Sul mio laptop dual core da 2,5 GHz ciò significa 279 ms: 785 ms per la raccolta di 50 milioni di eventi non iscritti.). Per gli hot spot dell'applicazione, questo potrebbe essere un problema da considerare.

Sì, in C # 6.0 - https://msdn.microsoft.com/en-us/magazine/dn802602.aspx .

object?.SomeMethod()

Questo articolo di Ian Griffiths offre due diverse soluzioni al problema che, conclude, sono trucchi accurati che non dovresti usare.

Cerating extention metodo come quello suggerito non risolve realmente i problemi con le condizioni di gara, ma piuttosto li nasconde.

public static void SafeInvoke(this EventHandler handler, object sender)
{
    if (handler != null) handler(sender, EventArgs.Empty);
}

Come affermato, questo codice è l'equivalente elegante della soluzione con variabile temporanea, ma ...

Il problema è che è possibile che l'abbonato all'evento possa essere chiamato DOPO che si è cancellato dall'evento . Ciò è possibile perché l'annullamento della sottoscrizione può avvenire dopo che l'istanza del delegato viene copiata nella variabile temporanea (o passata come parametro nel metodo precedente), ma prima che venga richiamato il delegato.

In generale, il comportamento del codice client è imprevedibile in questo caso: lo stato del componente non può già consentire di gestire la notifica degli eventi. È possibile scrivere il codice del client nel modo in cui gestirlo, ma porrebbe al client una responsabilità inutile.

L'unico modo noto per garantire la sicurezza del thread è utilizzare l'istruzione lock per il mittente dell'evento. Ciò garantisce che tutte le sottoscrizioni \ unsubscriptions \ invocation siano serializzate.

Per essere più accurati, il blocco dovrebbe essere applicato allo stesso oggetto di sincronizzazione utilizzato nei metodi della funzione di accesso agli eventi aggiungi \ rimuovi che è il valore predefinito "questo".

Sono d'accordo con la risposta di Kenny Eliasson. Vai con i metodi di estensione. Ecco una breve panoramica dei metodi di estensione e del metodo IfNotNull richiesto.

Metodi di estensione (metodo IfNotNull)

Forse non meglio ma a mio avviso più leggibile è creare un metodo di estensione

public static bool IsNull(this object obj) {
 return obj == null;
}

C'è un operatore null poco conosciuto in C # per questo, ??. Può essere utile:

http://weblogs.asp.net/scottgu/archive/2007/09/20/the-new-c-null-coalescing-operator-and-using-it-with-linq.aspx