views:

507

answers:

6

Hi,

I would like to know your opinions on which you find is a better approach to have a list filled up by a different method. I know there isn't a definite answer, but I would like to see reasonable pros and cons.

Approach 1.

private List<Snap> snapList;
snapList = getSnapList();

Approach 2.

private List<Snap> snapList = new ArrayList<Snap>();
fillSnapList(snapList);

Thanks, Matyas

+2  A: 

This totally depends on your context.

Scooterville
+2  A: 

Why not follow the Java API's Collections class and make your fill methods static (if it makes sense and is independent of object state).

Collections.fill( mylist, 0 );

like

MyListFiller.fill( myList, args );

At any rate, creating a filler interface makes sense if the fill method plans to change. If you're not really "filling", but returning object state of some kind, just have the given method build the List and return it.

public List<Object> getMyStuff()
{
//build and return my stuff
}
Stefan Kendall
I like the static method idea. I am stuck however, as I want to have an interface for the fill method to be able to leverage dependency injection. However I can't have static methods defined in an interface. What do you suggest?
Matyas
Make a filler interface with a fill method. It will work much the same as having a single static class. Rather than MyFiller.fill, you get filler.fill.
Stefan Kendall
A: 

One con for the first option is that the method name you have choosen (getSnapList()) is often considered a simple accessor, ie return the reference for the field snapList. In your design, it is implied that you will be creating the list if it doesnt exist and filling it with data, which would be introducing a side effect to the normal idiom.

Due to this and as it is better to be explicit, I prefer the second option.

akf
+3  A: 

I like approach 1 better than approach 2, because the list is really the output of the method that you're calling. Approach 1 makes that more clear than approach 2.

Also, approach 1 gives the method the opportunity to return an unmodifyable list. You might want this if the list should be filled once and shouldn't be modified later.

Java is not a functional programming language, but the first approach is more in the functional programming style than the second approach (in functional programming, immutability and avoiding mutable state are important ideas - and one important advantage of those is that they make concurrent programming easier, which is also useful in a non-functional programming language).

Jesper
Hey, very good arguments... and love functional perspective :)
helios
+2  A: 

It depends on the situation.

A method like getSnapList() is appropriate in situations like the following:

  1. The method you're writing doesn't want to care about where the list came from.
  2. The method shouldn't know what kind of list it's getting - for example, if you want to change to using a LinkedList, then you can do it in getSnapList() instead of all the methods that call fillSnapList().
  3. You will only ever want to fill new lists.

A method like fillSnapList() is appropriate in situations like the following:

  1. You may want to fill the list more than one time.
  2. You may want to vary the way the list is filled (i.e. what gets put into it).
  3. You need to fill a list that someone else hands you.
  4. You need to share the list among more than one class or object, and you might need to refill it at some point in its lifespan.
jprete
A: 

I prefer approach #1 because the method can be overridden by a sub class that would want to use a different List implementation. Also, I think that naming a factory method as a getter is confusing, I would rather name it newSnapList() or createSnapList().

Gaël Marziou