Can I add to a private list directly via a getter?

I realize that I will be ablaze with not just writing the test myself ... but I'm curious about people's opinions, not just functionality, so ... here goes ...

I have a class that has a private list. I want to add to this private list via the public getMyList () method.

so ... will this work?

public class ObA{
 private List<String> foo;
public List<String> getFoo(){return foo;}
}

public class ObB{
   public void dealWithObAFoo(ObA obA){
     obA.getFoo().add("hello");

   }
}

      

0


a source to share


5 answers


Yes, it will absolutely work - which is usually bad. (This is because you are actually returning a reference to the collection object, not a copy of the collection itself.)



Very often, you want to provide genuine read-only access to the collection, which usually means returning a read-only wrapper around the collection. Creating a return type for a read-only interface that is implemented by an assembly and returns an actual reference to the collection does not provide much protection: the caller can easily convert to a "real" collection type and then add without any problem.

+4


a source


Really not a good idea. Don't publish your mutable members outside, make a copy if you can't provide a readable version on the fly ...



public class ObA{
  private List<String> foo;
  public List<String> getFoo(){return Collections.unmodifiableList(foo);}
  public void addString(String value) { foo.add(value); }
}

      

+2


a source


If you want an opinion on this, I'll remove the call getFoo()

and add the methods add(String msg)

and remove(String msg)

(or any other functions you want to expose) to ObA

+1


a source


Granting access to a collection always seems bad in my experience - mainly because it is nearly impossible for them to control as soon as they come out. I am used to NEVER allowing direct access to collections outside of the class that contains them.

The main reason for this is that there is almost always some kind of business logic related to the dataset - for example, checking for addition, or perhaps at some point you will need to add a second closely related collection.

If you allow access as you say, it will be very difficult to make such a modification in the future.

Oh, also I often find that I end up having to store a little more data with the object I store, so I create a new object (only known inside the "Container" that the collection is in) and I put the object inside, before than to put it in the collection.

If you have locked your collection this is a trivial refactor. Try to imagine how difficult it would be in some case to work on something where you have not blocked data collection ...

+1


a source


If you want to support add and remove functionality in Foo, I would suggest the addFoo () and removeFoo () methods. Ideally, you could eliminate getFoo together by creating a method for each piece of functionality that you need. This makes it clear that the functions that the caller will list.

+1


a source







All Articles