Best practice regarding private arraylist and other similar designs

Question

I have the following class that I'm struggling with how to implement it. The question is whether it makes sense to have a private collection, in this case an arraialist, a member. I know well that it is considered best practice to have getters and setters for any members of the class, but in this case having a getter and setter will require re-implementation (or rather duplication) of large amounts of ArrayList functionality.

Class Example:

public class Email { private ArrayList<String> To; private ArrayList<String> Cc; private ArrayList<String> Bcc; ... } 

I guess I should really use getters and setters for these arrays? Is there some kind of approach that I have not thought about how to handle this situation? A simple solution to managing these lists is to set the private modifiers to the public ones and verify that the array data is valid on calls, but is this true? Can someone point me towards other SO issues, design patterns, etc. Should I consider?

Answer 1

Actually, in this case, I think it is better not to provide a direct getter / setter combination.

I would rather approach it as follows:

• Change the type to List<String> (best to use field interfaces.)
• Initialize an empty ArrayList constructor in the constructor.
• Provide delegates for add , remove , hasTo/Cc/Bcc .

Thus, you can decorate each collection with additional functions, for example. making sure the string contains valid recipient information.

 public void addTo(String recipient){ // validate recipient this.to.add(recipient); } public String removeTo(String recipient){ return this.to.remove(recipient); } public boolean hasTo(){ return this.to.size() > 0; } 

EDIT

I forgot to mention that getter makes sense, as you need it when processing email. But look at another answer to the question of returning an immutable List .

Answer 2

I well know that it is considered the best practice to have getters and setters for any members of the class.

I disagree. Just expose what you need! Try to think in terms of ADT (abstract data types). In other words, create an abstraction layer from the inner ArrayLists . Anyone using your class should not know that you are using ArrayLists internally. If absolutely necessary, you should not provide a getter for your ArrayLists . If you think you need it, consider returning a List and using Collections.unmodifiableList() to prevent modification via getter.

Answer 3

I know well that it is considered best practice to have getters and setters for any members of the class.

This is not true.

The relevant “best practice” recommendation should NOT disclose class states as fields.

If you need to make the state visible, then the recipients and setters are one option, but not necessarily the most suitable option. When deciding which option is best, you need to consider issues such as:

• Is there a state where I am detailing an internal ADT implementation or a reference to a separate data object?

• If I talk about the internal implementation details, how can I prevent something depending on it or (even worse) change it in potentially destructive ways?

Well-implemented recipients and setters can solve these problems; for example, by returning copies of collections or non-modifiable wrappers and / or by copying arguments to the collection. But wrapper methods can do the same, often with less runtime.

Another thing to consider is whether there are performance imperatives that make it necessary to avoid the principles of "best practice" and deliberately make the ADT "leaky."