处理对象层次结构中空引用的更好方法

发布于 2024-07-18 01:23:46 字数 326 浏览 7 评论 0原文

我正在寻找一种好方法来处理对象层次结构中的空引用。

即：

if(null == Object1.Object2.Object3.Property)

如果 Object2 为 null，则此示例将引发 Null Reference 异常。

就我而言，我不在乎什么是空的，只关心有什么东西是空的。我真的不想在我想做这样的事情的每个地方都放置 try/catch，所以我一直在寻找替代方案。

我已经尝试过 ?? 运算符，但这会在两级之后产生一些看起来很难看的代码。

任何想法表示赞赏。

原文

I’m looking for a nice way to handle a null reference in object hierarchy.

ie:

if(null == Object1.Object2.Object3.Property)

This example will throw a Null Reference exception if say Object2 is null.

In my case I don't care what is null, just that something is.
I don't really want to put try/catches around each place that I want to do something like this, so I’ve been looking for an alternative.

I've experimented with the ?? operator but this makes for some ugly looking code after two levels.

Any ideas appreciated.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

滥情稳全场 2024-07-25 01:23:46

现在这可能是切线......但我建议更改设计以避免丑陋和痛苦

调用 Object1.Object2.Object3.Property 违反德米特定律。相反，如果您应该访问该属性，则 Object1 应该公开一个属性本身...因此您应该调用 Object1.RetrievedFromTheDepthsProperty
为什么需要这样做……是因为，如果类型 Object2 的设计者将“Object3”字段/属性返回的对象类型更改为不具有您正在查找的属性的对象类型，那么您就会被淘汰。客户端对Object1的内部结构了解太多。如果 Object1 封装了数据在内部的位置，那么您就可以安全地应对未来的更改。此外，该属性还可以根据需要在内部进行所有空检查...让您更加干净

if (Object1.RetrievedFromTheDepthsProperty == null) {...}

Now this might be on a tangent... but I'd suggest a design change to avoid the ugliness and pain

Calling Object1.Object2.Object3.Property violates the law of demeter. Instead if you're supposed to get to that property, Object1 should expose a Property itself... So you should be calling Object1.RetrievedFromTheDepthsProperty
Why this is needed.. is that if the designer of the Type Object2 changes the type of Object returned by the 'Object3' field/property to one that doesn't have the Property you're looking for, you'd be hosed. The client knows too much about the internal structure of Object1. If Object1 encapsulated where the data is located internally, you'd be safe against future changes. Also this property can do all the null checking internally as required... leaving you with the much cleaner

if (Object1.RetrievedFromTheDepthsProperty == null) {...}

回复收藏 0 原文

尸血腥色 2024-07-25 01:23:46

这种情况（空安全解除引用）偶尔会出现，但不会；目前没有简洁的答案，除了：

if(Object1 == null || Object1.Object2 == null
        || Object1.Object2.Object3 == null
        || Object1.Object2.Object3.Property == null)

如果需要的话，您可以进行一些小的缓存（通过引入变量），但这会变得更加丑陋：

SomeType2 obj2;
SomeType3 obj3;
if(Object1 == null || (obj2 = Object1.Object2) == null
        || (obj3 = obj2.Object3) == null
        || obj3.Property == null)

一般来说，我会建议反对上述内容，除非您真的，真的< /em> 不想调用一个属性两次（因为它比属性应该做更多的工作）

This (null-safe dereferencing) is something that gets raised occasionally, and no; there is no tidy answer at the moment, other than:

if(Object1 == null || Object1.Object2 == null
        || Object1.Object2.Object3 == null
        || Object1.Object2.Object3.Property == null)

You can do some minor caching if you need (by introducing variables) but that gets even uglier:

SomeType2 obj2;
SomeType3 obj3;
if(Object1 == null || (obj2 = Object1.Object2) == null
        || (obj3 = obj2.Object3) == null
        || obj3.Property == null)

In general, I would advise against the above unless you really, really don't want to call a property twice (because it does more work than a property should)

回复收藏 0 原文

昇り龍 2024-07-25 01:23:46

您可以使用空对象模式。

class Car {
    Engine engine = null;

    public Engine Engine { 
        get { 
            return engine ?? new NullEngine();
        }
    }
}

class Engine {
    string make;
    public virtual string Make { get { return make; } }
}

class NullEngine : Engine {
    public override string Make { get { return null; } }
}

然后你可以这样做：

Car car;
if (car.Engine.Make != null) Console.WriteLine(car.Engine.Make);

而不是：

Car car;
if (car.Engine != null && car.Engine.Make != null) Console.WriteLine(car.Engine.Make);

请注意，为整个模型定义“空对象”需要做很多工作。您还需要非常小心，以免模型的用户感到困惑。如果您传递 null 并忘记检查它，代码往往会很快崩溃，但“null 对象”可以更容易地在调用堆栈深处生存并导致微妙的问题，因为它不是真正的对象。

You could use the Null Object pattern.

class Car {
    Engine engine = null;

    public Engine Engine { 
        get { 
            return engine ?? new NullEngine();
        }
    }
}

class Engine {
    string make;
    public virtual string Make { get { return make; } }
}

class NullEngine : Engine {
    public override string Make { get { return null; } }
}

Then you could do:

Car car;
if (car.Engine.Make != null) Console.WriteLine(car.Engine.Make);

Instead of:

Car car;
if (car.Engine != null && car.Engine.Make != null) Console.WriteLine(car.Engine.Make);

Note that it is quite a lot of work to define "null objects" for your entire model. You also need to take great care so that you do not confuse the users of your model. Code tend to blow up quickly if you pass null around and forget to check for it, but a "null object" can easier survive deep into the callstack and cause subtle problems since it isn't a real object.

回复收藏 0 原文