在 C # 中执行 null 检查的更干净的方法？

尽管我非常喜欢 C # ，但是在直接处理对象实例时，这是 C + + 非常讨人喜欢的一点; 一些简单的 不能声明是 null，所以不需要检查 null。

在 C # 中分得一杯羹的最好方法是使用 struct(这可能有点过于重新设计了——在这种情况下，从其他答案中选择一个)。虽然您可能会发现自己处于一个结构具有未实例化的“默认”值(即0.0.0，null 字符串)的情况下，但是从来不需要检查“ if (myStruct = = null)”。

当然，我不会在不了解它们的用途的情况下转而使用它们。它们往往用于值类型，而不是真正用于大块的数据——任何时候你把一个结构从一个变量分配给另一个变量，你往往实际上是在复制数据，本质上是在创建每个原始值的副本(你可以用 ref关键字避免这种情况——再次强调，仔细阅读它，而不是仅仅使用它)。尽管如此，它可能适用于像 StreetAddress 这样的东西——我当然不会懒惰地在任何我不想使用 null 检查的东西上使用它。

我有一个可能对此有用的扩展; ValueOrDefault ()。它接受一个 lambda 语句并对其进行计算，如果抛出任何预期异常(NRE 或 IOE) ，则返回计算值或默认值。

    /// <summary>
/// Provides a null-safe member accessor that will return either the result of the lambda or the specified default value.
/// </summary>
/// <typeparam name="TIn">The type of the in.</typeparam>
/// <typeparam name="TOut">The type of the out.</typeparam>
/// <param name="input">The input.</param>
/// <param name="projection">A lambda specifying the value to produce.</param>
/// <param name="defaultValue">The default value to use if the projection or any parent is null.</param>
/// <returns>the result of the lambda, or the specified default value if any reference in the lambda is null.</returns>
public static TOut ValueOrDefault<TIn, TOut>(this TIn input, Func<TIn, TOut> projection, TOut defaultValue)
{
try
{
var result = projection(input);
if (result == null) result = defaultValue;
return result;
}
catch (NullReferenceException) //most reference types throw this on a null instance
{
return defaultValue;
}
catch (InvalidOperationException) //Nullable<T> throws this when accessing Value
{
return defaultValue;
}
}


/// <summary>
/// Provides a null-safe member accessor that will return either the result of the lambda or the default value for the type.
/// </summary>
/// <typeparam name="TIn">The type of the in.</typeparam>
/// <typeparam name="TOut">The type of the out.</typeparam>
/// <param name="input">The input.</param>
/// <param name="projection">A lambda specifying the value to produce.</param>
/// <returns>the result of the lambda, or default(TOut) if any reference in the lambda is null.</returns>
public static TOut ValueOrDefault<TIn, TOut>(this TIn input, Func<TIn, TOut> projection)
{
return input.ValueOrDefault(projection, default(TOut));
}

不接受特定默认值的重载对于任何引用类型都将返回 null。这在你的场景中应该是可行的:

class test
{
private test()
{
var person = new Person();
if (person.ValueOrDefault(p=>p.contact.address.city) != null)
{
//the above will return null without exception if any member in the chain is null
}
}
}

与需要检查空引用相比，您的代码可能有更大的问题。就目前而言，您可能违反了 得墨忒耳定律。

得墨忒尔定律是一种启发式方法，比如“不要重复自己”，它可以帮助您编写易于维护的代码。它告诉程序员不要访问离直接作用域太远的任何东西。例如，假设我有这样的代码:

public interface BusinessData {
public decimal Money { get; set; }
}


public class BusinessCalculator : ICalculator {
public BusinessData CalculateMoney() {
// snip
}
}


public BusinessController : IController {
public void DoAnAction() {
var businessDA = new BusinessCalculator().CalculateMoney();
Console.WriteLine(businessDA.Money * 100d);
}
}

DoAnAction方法违反了得墨忒耳定律。在一个函数中，它访问 BusinessCalcualtor、 BusinessData和 decimal。这意味着，如果进行以下任何更改，则必须对该行进行重构:

• BusinessCalculator.CalculateMoney()的返回类型发生变化。
• BusinessData.Money的类型发生变化

考虑到过去的情况，这些变化很可能发生。如果像这样的代码是在整个代码库中编写的，那么进行这些更改可能会变得非常昂贵。此外，这意味着您的 BusinessController耦合到 BusinessCalculator和 BusinessData类型。

避免这种情况的一种方法是像下面这样重写代码:

public class BusinessCalculator : ICalculator {
private BusinessData CalculateMoney() {
// snip
}
public decimal CalculateCents() {
return CalculateMoney().Money * 100d;
}
}


public BusinessController : IController {
public void DoAnAction() {
Console.WriteLine(new BusinessCalculator().CalculateCents());
}
}

现在，如果进行上述任何一项更改，只需重构另一段代码，即 BusinessCalculator.CalculateCents()方法。您还消除了 BusinessController对 BusinessData的依赖。

您的代码遇到了类似的问题:

interface IContact
{
IAddress address { get; set; }
}


interface IAddress
{
string city { get; set; }
}


class Person : IPerson
{
public IContact contact { get; set; }
}


class Test {
public void Main() {
var contact = new Person().contact;
var address = contact.address;
var city = address.city;
Console.WriteLine(city);
}
}

如果做出以下任何改变，您将需要重构我写的主方法或您写的空检查:

• IPerson.contact的类型发生变化
• IContact.address的类型发生变化
• IAddress.city的类型发生变化

我认为您应该考虑对代码进行更深入的重构，而不仅仅是重写空检查。

也就是说，我认为有时候遵循得墨忒尔定律是不合适的。(毕竟，这是一种启发式规则，而不是硬性规则，尽管它被称为“法律”。)

特别是，我认为如果:

1. 有些类表示存储在程序的持久层 AND 中的记录
2. 您非常自信将来不需要重构这些类,

忽视得墨忒耳定律是可以接受的，尤其是在处理这些类别的时候。这是因为它们表示应用程序使用的数据，所以从一个数据对象到另一个数据对象是探索程序中信息的一种方式。在我上面的例子中，违反得墨忒尔定律导致的耦合要严重得多: 我从堆栈顶部附近的控制器，通过堆栈中间的业务逻辑计算器，一直到达可能位于持久层的数据类。

我将这个潜在的例外提到了 Demeter 定律，因为使用像 Person、 Contact和 Address这样的名称，您的类看起来可能是数据层 POCO。如果是这样的话，并且你非常有信心在将来不需要重构它们，那么在你的特定情况下，你也许可以忽略得墨忒耳定律。

根据使用“ city”变量的目的，一种更简单的方法是将 null 检查分离到不同的类中。这样你也不会违反得墨忒尔定律。所以不是:

if (person != null && person.contact != null && person.contact.address != null && person.contact.address.city != null)
{
// do some stuff here..
}

你会:

class test
{
private test()
{
var person = new Person();
if (person != null)
{
person.doSomething();
}
}
}


...


/* Person class */
doSomething()
{
if (contact != null)
{
contact.doSomething();
}
}


...


/* Contact class */
doSomething()
{
if (address != null)
{
address.doSomething();
}
}


...


/* Address class */
doSomething()
{
if (city != null)
{
// do something with city
}
}

同样，这取决于程序的目的。

在什么情况下这些东西可以是无效的？如果 null 表示代码中存在 bug，那么您可以使用代码契约。如果您在测试期间得到 null，那么他们将拾起它，然后在生产版本中消失。就像这样:

using System.Diagnostics.Contracts;


[ContractClass(typeof(IContactContract))]
interface IContact
{
IAddress address { get; set; }
}


[ContractClassFor(typeof(IContact))]
internal abstract class IContactContract: IContact
{
IAddress address
{
get
{
Contract.Ensures(Contract.Result<IAddress>() != null);
return default(IAddress); // dummy return
}
}
}


[ContractClass(typeof(IAddressContract))]
interface IAddress
{
string city { get; set; }
}


[ContractClassFor(typeof(IAddress))]
internal abstract class IAddressContract: IAddress
{
string city
{
get
{
Contract.Ensures(Contract.Result<string>() != null);
return default(string); // dummy return
}
}
}


class Person
{
[ContractInvariantMethod]
protected void ObjectInvariant()
{
Contract.Invariant(contact != null);
}
public IContact contact { get; set; }
}


class test
{
private test()
{
var person = new Person();
Contract.Assert(person != null);
if (person.contact.address.city != null)
{
// If you get here, person cannot be null, person.contact cannot be null
// person.contact.address cannot be null and person.contact.address.city     cannot be null.
}
}
}

当然，如果可能的 null 来自其他地方，那么您需要已经对数据进行了条件化处理。如果有任何 null 是有效的，那么您不应该将非 null 作为契约的一部分，您需要对它们进行测试并适当地处理它们。

消除方法中空检查的一种方法是在其他地方封装它们的功能。一种方法是通过 getter 和 setter。例如，与其这样做:

class Person : IPerson
{
public IContact contact { get; set; }
}

这样做:

class Person : IPerson
{
public IContact contact
{
get
{
// This initializes the property if it is null.
// That way, anytime you access the property "contact" in your code,
// it will check to see if it is null and initialize if needed.
if(_contact == null)
{
_contact = new Contact();
}
return _contact;
}
set
{
_contact = value;
}
}
private IContact _contact;
}

然后，无论何时调用“ person. contact”，“ get”方法中的代码都会运行，因此如果值为 null，就会初始化该值。

您可以将这种完全相同的方法应用于所有类型中可能为空的所有属性。这种方法的好处是: 1)防止您不得不在行中执行 null 检查，2)使代码更具可读性，并且不易出现复制粘贴错误。

但是，应该注意的是，如果您发现自己处于这样一种情况，即如果属性 是 null 之一(即，一个 Person with a null Contact 实际上在您的域中有什么含义吗?) ，那么需要执行某些操作，那么这种方法将是一个障碍，而不是帮助。但是，如果有问题的属性 永远不会应该为 null，那么这种方法将为您提供一种非常简洁的方式来表示这个事实。

—— jtlovetteiii

这样的引用链可能会发生，例如，如果您使用 ORM 工具，并希望尽可能保持类的纯粹性。在这种情况下，我认为这是不可避免的。

我有下面的扩展方法“ family”，它检查调用它的对象是否为 null，如果不是，返回它请求的属性之一，或者用它执行一些方法。当然，这只适用于引用类型，这就是为什么我有相应的泛型约束的原因。

public static TRet NullOr<T, TRet>(this T obj, Func<T, TRet> getter) where T : class
{
return obj != null ? getter(obj) : default(TRet);
}


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

与手动解决方案相比，这些方法几乎没有增加任何开销(没有反射，没有表达式树) ，并且可以使用它们实现更好的语法(IMO)。

var city = person.NullOr(e => e.Contact).NullOr(e => e.Address).NullOr(e => e.City);
if (city != null)
// do something...

或者使用方法:

person.NullOrDo(p => p.GoToWork());

然而，可以肯定地说，代码的长度并没有发生太大的变化。

您可以使用反射，以避免在每个类中强制实现接口和额外的代码。只是一个具有静态方法的 Helper 类。这可能不是最有效的方法，对我温柔点，我是个处女(读书，菜鸟)。.

public class Helper
{
public static bool IsNull(object o, params string[] prop)
{
if (o == null)
return true;


var v = o;
foreach (string s in prop)
{
PropertyInfo pi = v.GetType().GetProperty(s); //Set flags if not only public props
v = (pi != null)? pi.GetValue(v, null) : null;
if (v == null)
return true;
}


return false;
}
}


//In use
isNull = Helper.IsNull(p, "ContactPerson", "TheCity");

当然，如果你在程序名中有一个打字错误，结果将是错误的(最有可能的)。