0

I'm a beginner programmer in Java, so this may sound like a simple and rather silly question:

In Java, is it better to use a method to get a property value or just use the property itself?

To see what I mean, look at this example from a page from the Oracle Java Tutorials about Lambda Expressions:

processPersons(
    roster,
    p -> p.getGender() == Person.Sex.MALE
        && p.getAge() >= 18
        && p.getAge() <= 25,
    p -> p.printPerson()
);

I'm just wondering, what would be the use of evoking p.getGender() and p.getAge() when just using p.gender and p.age should have the right values? They can't have multiple values or anything that could prevent them from just using the properties. (p.printPerson() is fine because it might print out multiple property values.)

I mean, to run the above code, they would need to have a constructor to assign properties and extra methods just to return the property values, like so:

public class Person {
    public String name;
    public int age;
    public String gender;
    public Person(String name, int age, String gender) {
        this.name = name;
        this.age = age;
        this.gender = gender;
        // assign some other properties for "printperson()" to print out
    }
    public String printPerson() {
        return name;    // and maybe return some other values
    }

    // need the methods below just to return property values??? are they unnecessary??
    public String getGender() {
        return this.gender;  // can't they use "p.gender" to get this value?
    }
    public int getAge() {
        return this.age;     // can't they use "p.age" to get this value?
    }
}

Some of my reasoning is assumptions from my limited programming knowledge, so please correct me if I'm wrong.

Is there something I'm missing, a reason why to use methods to get property values? Or was it just used as a example? Because it would seem much simpler to not have to evoke methods and slow the program down.

Any thoughts are appreciated.

Jonathan Lam
  • 16,831
  • 17
  • 68
  • 94
  • It is not recommended to use public properties for security reasons, that's why we use methods for `get` and `set`. This way you only get/set properties that are meant to be changed – David Zhou Jul 08 '14 at 21:03
  • @DavidZhou Why not? Especially for small, not-important small programs, like the ones they show and the ones I make, would it be fine? – Jonathan Lam Jul 08 '14 at 21:05
  • 1
    In Java, the 'gospel' generally goes "private members accessed via accessors". Sometimes, accessors are completely useless and serve as nothing more than boilerplate code. Should you getters/setters for larger projects, team projects, etc? Usually. Are they always 100% needed or make sense? No. Sometimes they are just pointless. – Joseph Boyle Jul 08 '14 at 21:06
  • Yes, if you are doing something locally, it really doesn't matter. But you should get used to use get/set – David Zhou Jul 08 '14 at 21:07
  • 2
    Yes. And no. Maybe. The theory is that the property should be "protected" from arbitrary access/modification. Even if the getter and setter are just doing plain copies in and out. When you question this the argument is presented that sometime in the future you might want to protect the value from arbitrary access or surround it with checking or logging code or some such. This argument is valid but, in many circumstances, too weak to really justify the added complexity. – Hot Licks Jul 08 '14 at 21:08
  • @DavidZhou I'll keep that in mind from now on thanks – Jonathan Lam Jul 08 '14 at 21:08
  • 1
    There is the valid argument that coding in a large app is a lot simpler if access is standardized. If some properties are accessed directly and others via setter/getter then it's harder to know how to access a property in a specific case. That to me is the most compelling argument for always using setters/getters, but not sufficient to override the simplicity of direct access in some cases (especially closely-connected code and smaller apps). – Hot Licks Jul 08 '14 at 21:11
  • this is a weakness of the language where Java never got on board with the Universal Access principle. anyway this seems like a clear-cut duplicate. – Nathan Hughes Jul 08 '14 at 21:16

1 Answers1

1

Reference: Effective Java Item 14 In public classes, use accessor methods, not public fields.

if a class is accessible outside its package, provide accessor methods, to preserve the flexibility to change the class’s internal representation. If a public class exposes its data fields, all hope of changing its representation is lost, as client code can be distributed far and wide.

Stelium
  • 1,207
  • 1
  • 12
  • 23