为null对象设置方法返回值是否有用?

时间:2022-09-25 12:54:29

Would it be useful to be able to provide method return value for null objects?

能够为null对象提供方法返回值是否有用?

For a List the null return values might be:

对于List,null返回值可能是:

get(int) : null
size() : 0
iterator() : empty iterator

That would allow the following code that has less null checks.

这将允许以下代码具有较少的空检查。

List items = null;

if(something) {
    items = ...
}

for(int index = 0; index < items.size(); index++) {
    Object obj = items.get(index);
}

This would only be used if the class or interface defined it and a null check would still work. Sometimes you don't want to do null checks so it seems like it could be beneficial to have this as an option.

只有在类或接口定义它并且空检查仍然有效时才会使用此方法。有时您不想进行空检查,因此将此选项作为选项似乎是有益的。

From: http://jamesjava.blogspot.com/2007/05/method-return-values-for-null-objects.html

5 个解决方案

#1


3  

It is nice to not have to check for NULL, and some languages make it easier -- e.g. C#'s non-NULLable types, or Haskell which doesn't have NULLs but can express a missing value with the Maybe type constructor.

不必检查NULL是很好的,有些语言可以让它更容易 - 例如C#的非NULLable类型,或Haskell,它没有NULL但可以用Maybe类型构造函数表示缺失值。

A NULL is distinct from an empty list. You can take the point-of-view that someone passing in a NULL where you need a list is making a programming error, and that the right thing to do is throw a NullPointerException.

NULL与空列表不同。您可以采用某种观点,即在需要列表的情况下传入NULL的人正在编写编程错误,并且正确的做法是抛出NullPointerException。

The typical excuse for accepting NULLs is that often there's a case where you don't need the list, and you shouldn't have to create a new List that's empty, especially when there's some concern about efficiency. You can have many of the benefits without changing the language, but by instead having a static EmptyList that people can pass in, that never needs to be reinitialized.

接受NULL的典型借口是,通常情况下您不需要列表,并且您不必创建一个空的新List,尤其是在对效率有一些担忧时。你可以在不改变语言的情况下获得许多好处,但是通过拥有一个人们可以传入的静态EmptyList,永远不需要重新初始化。

#2


2  

It's a pattern called Null Object

这是一个名为Null Object的模式

http://en.wikipedia.org/wiki/Null_Object_pattern

#3


0  

This is a good idea.

这是一个好主意。

Smalltalk does this.

Smalltalk这样做。

There is a NULL object. It doesn't descend from Object. (Smalltalk is a singly-rooted class hierarchy like Java)

有一个NULL对象。它不会从Object下降。 (Smalltalk是像Java这样的单根类层次结构)

For the advanced student, you can sub-class it for making proxies!

对于高级学生,您可以将其分类以制作代理!

#4


0  

Ruby does this (as well as others). It has nil instead of null and it's an object.

Ruby做到了这一点(以及其他人)。它有nil而不是null,它是一个对象。

I dp hate when functions that are meant to return lists can return null. It's better to return an empty list and let the user decide if they want to check for null (empty) or not.

我憎恨当用于返回列表的函数可以返回null。最好返回一个空列表,让用户决定是否要检查null(空)。

#5


0  

In C# (among other languages), this is normally not allowed. Without an instance of Foo, .net doesn't know to call Foo's method or Foo's child's method.

在C#(以及其他语言)中,通常不允许这样做。没有Foo的实例,.net不知道调用Foo的方法或Foo的子方法。

However, an C# 3.0 extension method applied to the Foo type would allow this:

但是,应用于Foo类型的C#3.0扩展方法将允许:

Foo x = null;
if (x.Bar() == 0)
{
  Console.WriteLine("I win");
}

Bar could be constructed like so:

Bar可以像这样构建:

public static int Bar (this Foo theFoo)
{
  return theFoo == null ? 0 : 1;
}

#1


3  

It is nice to not have to check for NULL, and some languages make it easier -- e.g. C#'s non-NULLable types, or Haskell which doesn't have NULLs but can express a missing value with the Maybe type constructor.

不必检查NULL是很好的,有些语言可以让它更容易 - 例如C#的非NULLable类型,或Haskell,它没有NULL但可以用Maybe类型构造函数表示缺失值。

A NULL is distinct from an empty list. You can take the point-of-view that someone passing in a NULL where you need a list is making a programming error, and that the right thing to do is throw a NullPointerException.

NULL与空列表不同。您可以采用某种观点,即在需要列表的情况下传入NULL的人正在编写编程错误,并且正确的做法是抛出NullPointerException。

The typical excuse for accepting NULLs is that often there's a case where you don't need the list, and you shouldn't have to create a new List that's empty, especially when there's some concern about efficiency. You can have many of the benefits without changing the language, but by instead having a static EmptyList that people can pass in, that never needs to be reinitialized.

接受NULL的典型借口是,通常情况下您不需要列表,并且您不必创建一个空的新List,尤其是在对效率有一些担忧时。你可以在不改变语言的情况下获得许多好处,但是通过拥有一个人们可以传入的静态EmptyList,永远不需要重新初始化。

#2


2  

It's a pattern called Null Object

这是一个名为Null Object的模式

http://en.wikipedia.org/wiki/Null_Object_pattern

#3


0  

This is a good idea.

这是一个好主意。

Smalltalk does this.

Smalltalk这样做。

There is a NULL object. It doesn't descend from Object. (Smalltalk is a singly-rooted class hierarchy like Java)

有一个NULL对象。它不会从Object下降。 (Smalltalk是像Java这样的单根类层次结构)

For the advanced student, you can sub-class it for making proxies!

对于高级学生,您可以将其分类以制作代理!

#4


0  

Ruby does this (as well as others). It has nil instead of null and it's an object.

Ruby做到了这一点(以及其他人)。它有nil而不是null,它是一个对象。

I dp hate when functions that are meant to return lists can return null. It's better to return an empty list and let the user decide if they want to check for null (empty) or not.

我憎恨当用于返回列表的函数可以返回null。最好返回一个空列表,让用户决定是否要检查null(空)。

#5


0  

In C# (among other languages), this is normally not allowed. Without an instance of Foo, .net doesn't know to call Foo's method or Foo's child's method.

在C#(以及其他语言)中,通常不允许这样做。没有Foo的实例,.net不知道调用Foo的方法或Foo的子方法。

However, an C# 3.0 extension method applied to the Foo type would allow this:

但是,应用于Foo类型的C#3.0扩展方法将允许:

Foo x = null;
if (x.Bar() == 0)
{
  Console.WriteLine("I win");
}

Bar could be constructed like so:

Bar可以像这样构建:

public static int Bar (this Foo theFoo)
{
  return theFoo == null ? 0 : 1;
}