Java: null of default value of object is better_问答_开发者

The first case: There is a class that has another class as its data member. When this class is instantiated, what we should do with the data member?

(A) In constructor: this.anotherClass = new AnotherClass();
(B) left it null, no need to instantiate it.

The second case: There is a class that has an ArrayList as its data member. When this class is instantiated, what we should do with the ArrayList?

(A) In constructor: this.bulidingList = new ArrayList< Building >();
(B) left it null, no need to instantiate it.

The third case: when we create a method in which its return type is a collection, for example

public ArrayList< Building > getBuilding开发者_JAVA百科List(){ /// Bah Bah Bah.. }

if there is no Building, we should return the empty ArrayList "new ArrayList< Building >()" "or null.

I would prefer not using null to avoid potential NullPointerException's. To avoid creating unnecessary objects you could construct a single static instance to return, as long as it's immutable. As for an empty ArrayList, you can use Collections.emptyList() to do this for you.

In the end it's up to you how you want to define how your API works. Either way you should clearly document it so the caller knows what to expect.

What are your needs? My general preference is to return null when possible as this avoids creating another object in memory.

Provided that you ensure the documentation clearly states that the method may return null and it is the responsibility of calling code to handle that, I don't see a problem.

There is no concrete answer. It is a case of your API, or, speaking simpler, the expectations of the surrounded code.

Try to think in details about your getBuildingList(). Is it ok to return null? Or null is forbidden and you should return empty list?

Anyway, docuemtn you thoughts in javadoc for the method.

Given the destructive nature of Nulls in Java, I think it's a good practice to return empty collections rather then null collections.

For Objects, you should return "null" if the object has no values set internally.

Is a default-initialized object meaningful, as an empty ArrayList certainly is? Then instantiate it. Don't optimize prematurely.

On the other hand, if a default AnotherClass makes no sense, then leave the member as null.

Finally, if you run into performance or memory usage problems, consider revising the design.

In my opinion, it is best to design your APIs to avoid returning a null if there is a better alternative.

For collections, return an empty collection; e.g. Collections.emptyList() or new ArrayList() ... depending on the API requirements.
For arrays, return an array of length zero.
For objects, consider whether it is feasible to use a distinguished instance of the class, or to design the API so that the result can't be null in the first place.

If you do need to return null, or accept null as a method parameter, make sure that the javadoc clearly states that this is a valid result / argument ... and what it means.

The problem with APIs that use null is that developers forget about the null case and the result is an unexpected NullPointerException. You could say that's not the API designer's fault - the API user should have read the documentation. But that doesn't really address the issue. A better approach is to avoid returning the null in the first place, especially in cases where there is a simple alternative.

The other point is that a non-null value is generally easier for the caller to deal with. A null typically has to be dealt with as a special case by the calling code. A non-null value doesn't. For example, you can iterate over an empty collection or array using a for loop, but a null has to be tested for explicitly.

The third case: when we create a method in which its return type is a collection, for example

public ArrayList< Building > getBuildingList(){ /// Bah Bah Bah.. }

This is awful, a public member should never return an implementation type. The signature should be:

public List< Building > getBuildingList()

That way you can (and should) return Collections.emptyList() if your data is empty.

The first case: There is a class that has another class as its data member. When this class is instantiated, what we should do with the data member?

(A) In constructor: this.anotherClass = new AnotherClass();

(B) left it null, no need to instantiate it.

I would prefer (C) In constructor: require a non-null AnotherClass parameter.

If you need a default constructor and you always expect the caller to also call setAnotherClass() afterwards you could leave it null in the constructor and check for null when you actually use the field, otherwise you should probably create a default AnotherClass object in the constructor.

The second case: There is a class that has an ArrayList as its data member. When this class is instantiated, what we should do with the ArrayList?

(A) In constructor: this.bulidingList = new ArrayList< Building >(); (B) left it null, no need to instantiate it.

I would always instantiate it, but if the list is read-only I'd declare it this way instead:

List<Building> buildingList = Collections.emptyList();

The third case: when we create a method in which its return type is a collection, for example

public ArrayList< Building > getBuildingList(){ /// Bah Bah Bah.. }

if there is no Building, we should return the empty ArrayList "new ArrayList< Building >()" "or null.

I'm not especially proud about it, but I do sometimes return null when I want an additional return value, something like getBuildingsListAndReturnNullIfThereAreNoTenants. When you just want to say "I haven't found any buildings" it's always better to return an empty list instead.

Sometimes you can do an upfront check and return Collections.emptyList() instead of creating a new ArrayList<Building> instance, but I wouldn't go out of my way to do it.