In Java, when should we use a single, comprehensive getter method that can return many objects rather than a bunch of smaller getter methods? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 8 years ago.

Improve this question

To clarify, this is what I mean:

public Image getRespectiveImage(int temp) {
    switch(temp){
    case 1:return one;
    case 2:return two;
    case 3:return three;
    case 4:return four;
    case 5:return five;
    }
    return null;
}

compared to

public Image getOne(){return one;}
public Image getTwo(){return two;}
public Image getThree(){return three;}
public Image getFour(){return four;}
public Image getFive(){return five;}

I tend to prefer the former because it just seems simpler for some reason, but everyone seems to use the latter. Is there a reason why someone would use the bunch of getter methods?

Answer 1

It's not really about "which is better or worse" -- If the properties you are writing getters for are not, by nature, indexed, then it would make no sense to write an indexed getter for them. If your properties are not of the same type, that is a good clue that an indexed representation isn't generally going to be helpful.

If the properties you are using do make sense to store as an indexed list, then sure, by all means -- but then I would also use an array for the field (consider: If an array type is not appropriate for that field, then perhaps an indexed getter is not actually appropriate either).

You generally want your getters and setters to reflect the fields you have declared. You would use a getter/setter that takes an int index parameter when your field is an array type (which conforms to the JavaBeans spec, section 8.3.3).

You want to do this for two reasons. First, on a conceptual level, if your fields are significantly different from your getters/setters, while there are tons of valid reasons for this, you may want to take a look at how you've organized your fields to see if you can refactor to something that more accurately represents the purpose of your object (it is assumed that public getters/setters are good representations of this purpose). It may be an indication of bigger design issues.

Secondly, and this is more just about being aware of what you are doing, your getters and setters will affect interaction with APIs that operate on beans, and will also affect interaction with APIs that use reflection. For example, Hibernate can be configured to persist objects to a database using getter/setter properties, or direct field access. So depending on the configuration there, you have to at least be aware of your getter/setter vs. field setup.

The take home point here is: Don't try to come at this with the idea that there is a set of rules defining when one way is better or worse. Just consider the nature of the objects you are working with, and what their properties actually mean (semantics), and write a public interface that makes sense.

Answer 2

It's good practice to have getters and setters for all private variables that you want the user to interact with.

While your above solution simplifies, it will confuse other people that work with your code because it is not common practice.

Answer 3

It depends on the problem you're facing. There's nothing wrong with the first approach, even more if you use an "enum" to restrict and document the options:

enum ImageCategory {
  Unchecked,
  Checked,
  Disabled;
}

Image getRespectiveImage(ImageCategory category);

Just be sure that every "category" represents an instance of the same nature.

On the other side, it's clearly not a good thing to have a method like this:

Object get(String property);

Unless you're writing your own Dictionary/Map class.

Answer 4

Using a bunch of getter methods has two noticable advantages over the first approach.

1. The getter methods, when named properly, self document what it is that you're getting from the object.
2. In the first case, you would need to provide the user with some kind of documentation that tells them which input corresponds to return. This is not necessary when you have separate getters. (It places a greater burden on the clients)