Should I always use getter/setter methods in Java classes or are there times when its okay to use public attributes?

Question

I have been coding Java for about 4 months. I just started coding android games with the guide of an intro book. In the book, they do not encapsulate any attributes of classes.

Ex.

public class GameObject{
    public Vector position;
    public float angle;

    public GameObject(float angle, Vector position){
...

I was always told that encapsulation of attributes was good practice: only allow access to the private attributes through getter and setter methods.

Could any programmers with more experience than me tell me which way is the "proper" coding way of creating attributes? And of course why please?

And then a follow up: should I always encapsulate private attributes of a class and provide getter and setter methods, or are there situations where public attributes are okay?

Solution 1

Encapsulation is one of the core concepts of object oriented programming. Using getters and setters, is always, in my opinion good practice. One thing you should avoid is to have external entities mess with the internal structure of your class at will.

Typical example, consider having a dateOfBirth parameter. With a setter and getter you can have a small validation process, making sure that the user was not born in the future, or is impossibly old. You can also use the setter to update some other fields, such as age.

This minor validation can also enhance code re-usability since you do not need to have to make this check in any other class which invokes these getters and setters.

Solution 2

If we'll put the puristic view aside, we're left with two good reasons to use getters and setters -

1. It reduces the amount of code change you'll have to do in the future if you'd like to modify your behaviour. Consider the following cases you're suddenly required to make - validate some input, make some field calculated or have it affect other fields when changed, restrict the scope of get or set operations or make them uneven, modify the behaviour of the field in some inherited class or store the field in some bizarre manner. If you already have getters and setters in place - these changes cost you nothing besides the change itself. If not, you'll have to modify every usage of the fields in your project.

2. It allows you to do implement interfaces which require a getter or setter.

Solution 3

In most cases you should not think of a class as a set of attributes that you operate on externally, but as an entity that provides certain services to the application. Most attributes of the class will end up being private and not having get or set methods.

There are exceptions though: for example in some settings you will find classes that only hold values and have little or no logic themselves. The usual rule for these kinds of classes is to make fields private and provide get and set methods because once you make something public and some other class depends on it you can't change it. For example you may want to ensure that the value of a particular field is never null or do some other validation; if you used a set method you could add the check there, but if the field is public there's nothing you can do. Another example: you may want to change the field type to do some optimization, but if the field is public, there's nothing you can do.

All rules are meant to be broken though. If you know that you will never need get and set methods there's not much point in adding them. Some people may complain about "lack of encapsulation" but if every attribute of the class can be read and written from the outside anyway where's the encapsulation?