Initialize a collection within an object?

问题:

If an object has a property that is a collection, should the object create the collection object or make a consumer check for null? I know the consumer should not assume, just wondering if most people create the collection object if it is never added to.

回答1:

You can also use the "Lazy initailizer" pattern where the collection is not initialized until (and unless) someone accesses the property getter for it... This avoids the overhead of creating it in those cases where the parent object is instantiated for some other purpose that does not require the collection...

   public class Division
    {
        private int divId;
        public int DivisionId { get; set; }

        private Collection<Employee> emps;
        public Collection<Employee> Employees
        { get {return emps?? (emps = new Collection<Employee>(DivisionId));}} 
    }

EDIT: This implementation pattern is, in general, not thread safe... emps could be read by two different threads as null before first thread finishes modifying it. In this case, it probably does not matter as DivisionId is immutable and although both threads would get different collections, they would both be valid. Whne the second thread fihishes, therefore, emps would be a valid collection. The 'probably' is because it might be possible for the first thread to start using emps before the second thread resets it. That would not be thread-safe. Another slightly more complex implementation from Jon SKeet is thread-safe (see This article on SIngletons for his example/discussion on how to fix this.

回答2:

This depends on the contract you have between your API and the user.

Personally, I like a contract that makes the Object manage its collections, i.e., instantiating them on creation, and ensuring that they can't be set to null via a setter - possibly by providing methods to manage the collection rather than setting the collection itself.

i.e., addFoo(Foo toAdd) instead of setFooSet(Set set), and so on.

But it's up to you.

回答3:

I typically will create the collection then provide methods to add / remove items from the internal collection rather than making the consumer of the class worry about checking for null. This also gives you the ability to control better what happens to the collection. Ultimately it depends on what it is for, but most likely if your class has a collection it isn't just so that the consumer of the class can have a collection of those objects. Otherwise, why would they use your class?

回答4:

While what I say here is not universal by any means, I think collections are mostly suited as private properties which should be accessed by public methods on the object itself. Therefore, the object is responsible to create and destroy them as needed. This way, it won't be possible to set it to null from external code.

回答5:

I prefer to create the collection upon instantiation, provide add/remove methods in the containing object, and if needed, provide addAll/removeAll methods for adding and removing entire external collections. I never allow the collection object to be accessed for get or set by the caller - I may, however, provide a getter that returns a copy (poss. immutable) of the collection.

I have also had copy-on-write implementations which provide an immutably wrapped view, since any mutation will create a new underlying collection.

回答6:

I create an empty collection. Sure, it has a slight memory cost, but not a large enough one to be concerned about it.

回答7:

IMO, this is where IEnumerable comes in nicely.

Personally, I like my 'collection' properties to be initialized to empty lists.

回答8:

If the collection is an intrinsic part of the object, then the object should generally create it (and not allow the user to set it to a different collection instance).

回答9:

I've tried both ways and I am usually happy when I find I have already instanciated it. Alternatively you could hide the the implementation from the consumer behind a set of methods that can handle the check for you.

回答10:

As a general rule, I think the object should create the collection and provide methods for manipulating it; add/get/remove. When following this rule, you should not provide methods for setting the collection directly. If you want a method like setSomeCollection(Collection someCollection) for convenience, the implementation of this method should not set the reference within the object, but copy the values from the method parameter collection to the collection within the object;

public void setSomeCollection(Collection someCollection) {
   this.someCollection.clear();
   this.someCollection.addAll(someCollection);
}

You should do this, so clients of your API cannot get access to the collection that your class maintains. If they do, they can manipulate it without using objects of your class and violate constraints that your class guarantees.

The same is true if providing a getter; you should either return a copy of your internal colleciton, or a read-only version of it. Apache commons-collections and google-collections provide methods for creating immutable wrappers around a collection, aswell as the ones that come with Java in the java.util package; java.util.Collections.unmodifiable*.