问题描述
[ 这是 最佳实践的结果:函数应该返回 null 还是一个空对象? 但我试图变得非常一般.]
[ This is a result of Best Practice: Should functions return null or an empty object? but I'm trying to be very general. ]
在我见过的很多遗留(嗯...生产)C++ 代码中，有一种趋势是编写很多的NULL(或类似的) 检查以测试指针.当添加 NULL 时，其中许多会在发布周期结束时添加 - 检查提供了对指针取消引用导致的崩溃的快速修复 - 并且没有太多时间进行调查.
In a lot of legacy (um...production) C++ code that I've seen, there is a tendency to write a lot of NULL (or similar) checks to test pointers. Many of these get added near the end of a release cycle when adding a NULL-check provides a quick fix to a crash caused by the pointer dereference--and there isn't a lot of time to investigate.
为了解决这个问题，我开始编写采用 (const) 引用参数的代码，而不是(更)更常见的传递指针的技术.没有指针，不想检查 NULL(忽略实际有空引用的极端情况).
To combat this, I started to write code that took a (const) reference parameter instead of the (much) more common technique of passing a pointer. No pointer, no desire to check for NULL (ignoring the corner case of actually having a null reference).
在 C# 中，存在相同的 C++问题":希望根据 null (ArgumentNullException) 检查每个未知引用并快速修复 NullReferenceExceptions 通过添加一个 null 检查.
In C#, the same C++ "problem" is present: the desire to check every unknown reference against null (ArgumentNullException) and to quickly fix NullReferenceExceptions by adding a null check.
在我看来，防止这种情况的一种方法是首先通过使用空对象 (String.Empty, EventArgs.Empty) 来避免空对象.另一种方法是抛出异常而不是返回 null.
It seems to me, one way to prevent this is to avoid null objects in the first place by using empty objects (String.Empty, EventArgs.Empty) instead. Another would be to throw an exception rather than return null.
我刚刚开始学习 F#，但在那个环境中，空对象似乎少得多.所以也许你真的不需要有很多 null 引用浮动?
I'm just starting to learn F#, but it appears there are far fewer null objects in that enviroment. So maybe you don't really have to have a lot of null references floating around?
我在这里吠错树了吗?
推荐答案
我倾向于怀疑包含大量 NULL 的代码，并尝试在可能的情况下使用异常、空集合、Java Optionals 等重构它们.
I tend to be dubious of code with lots of NULLs, and try to refactor them away where possible with exceptions, empty collections, Java Optionals, and so on.
引入空对象"Martin Fowler 的 重构(第 260 页)中的模式可能也很有帮助.空对象响应真实对象会使用的所有方法，但以做正确的事"的方式.因此，与其总是检查 Order 以查看 order.getDiscountPolicy() 是否为 NULL，不如确保 Order 在这些情况下具有 NullDiscountPolicy.这简化了控制逻辑.
The "Introduce Null Object" pattern in Martin Fowler's Refactoring (page 260) may also be helpful. A Null Object responds to all the methods a real object would, but in a way that "does the right thing". So rather than always check an Order to see if order.getDiscountPolicy() is NULL, make sure the Order has a NullDiscountPolicy in these cases. This streamlines the control logic.
这篇关于空对象与空对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！