Виклик методу, якщо не нульовий у C #

Чи можна якось скоротити це твердження?

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

тому що я часто пишу це, і це стає досить прикро. Єдине, що я можу придумати, це реалізувати шаблон Null Object , але це не те, що я можу робити щоразу, і це, звичайно, не рішення для скорочення синтаксису.

І подібна проблема з подіями, де

public event Func<string> MyEvent;

а потім викликати

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

Починаючи з C # 6, ви можете просто використовувати:

MyEvent?.Invoke();

або:

obj?.SomeMethod();

Це ?.оператор, що поширює нуль, і призведе .Invoke()до короткого замикання, коли операнд є null. Операнд доступний лише один раз, тому немає ризику "зміни значення між перевіркою та викликом".

===

До C # 6, ні: не існує нульової безпеки магії, за одним винятком; методи розширення - наприклад:

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

тепер це дійсно:

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

У випадку подій, це має ту перевагу, що також видаляє умову перегони, тобто вам не потрібна тимчасова змінна. Тому зазвичай вам потрібно:

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

але з:

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

ми можемо використовувати просто:

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

Те, що ви шукаєте, - це оператор Null Conditional (не "злиття"):?. . Це доступно з C # 6.

Вашим прикладом буде obj?.SomeMethod();. Якщо obj має значення null, нічого не відбувається. Якщо у методу є аргументи, наприклад, obj?.SomeMethod(new Foo(), GetBar());аргументи не обчислюються, якщо objє значенням null, що має значення, якщо оцінка аргументів матиме побічні ефекти.

І ланцюжок можливий: myObject?.Items?[0]?.DoSomething()

Швидкий метод розширення:

    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();
        }
    }

приклад:

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

або альтернативно:

    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));
    }

приклад:

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

Події можна ініціалізувати порожнім делегатом за замовчуванням, який ніколи не видаляється:

public event EventHandler MyEvent = delegate { };

Не потрібно перевіряти нуль.

[ Оновлення , дякую Бевану, що вказав на це]

Однак пам’ятайте про можливий вплив на ефективність роботи. Швидкий мікротестер, який я зробив, вказує на те, що обробка події без підписників у 2-3 рази повільніша при використанні шаблону "делегат за замовчуванням". (На моєму двоядерному ноутбуці 2,5 ГГц це означає 279 мс: 785 мс для збору 50 мільйонів непідписаних подій.). Для гарячих точок щодо застосування це може бути проблемою для розгляду.

Так, у C # 6.0 - https://msdn.microsoft.com/en-us/magazine/dn802602.aspx .

object?.SomeMethod()

Ця стаття Яна Гріффітса пропонує два різні варіанти вирішення проблеми, які, на його думку, є акуратними трюками, якими ви не повинні користуватися.

Отриманий спосіб продовження, як запропонований, насправді не вирішує проблем з умовами перегонів, а навпаки, приховує їх.

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

Як зазначено, цей код є елегантним еквівалентом рішення з тимчасовою змінною, але ...

Проблема обох, що цілком можливо, що субцибер події може бути названий ПІСЛЯ відмови від події . Це можливо, оскільки скасування підписки може відбутися після того, як екземпляр делегата буде скопійовано у змінну temp (або передано як параметр у наведеному вище методі), але до того, як буде викликаний делегат.

Взагалі поведінка коду клієнта в цьому випадку непередбачувана: стан компонента вже не може обробляти повідомлення про події. Можна написати клієнтський код таким чином, щоб з ним обробляти, але це покладе на клієнта непотрібну відповідальність.

Єдиний відомий спосіб забезпечити безпеку потоку - використовувати оператор блокування для відправника події. Це гарантує, що всі підписки \ відписки \ виклик серіалізовані.

Щоб бути точнішим, блокування слід застосовувати до того самого об'єкта синхронізації, що використовується в методах додавання / видалення події, який за замовчуванням є "цим".

Я згоден з відповіддю Кенні Еліассона. Використовуйте методи розширення. Ось короткий огляд методів розширення та необхідного методу IfNotNull.

Методи розширення (метод IfNotNull)

Можливо, не краще, але, на мій погляд, більш читабельним є створення методу розширення

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

У C # для цього існує маловідомий нульовий оператор, ??. Може бути корисним:

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