Public fields in a Data Transfer Object

Question

In my years of programming I\'ve often made classes that simply group a few variables with their setters and getters. I\'ve seen these types of objects referred to as value

Answer 1

Most programmers will default to private fields with getters/setters without thinking about it. But like any cargo-cult thing, it's better to make a conscious decision.

The main reason for using a getter/setter combination instead of a public field is that you can change the definition. So, if your DTO is part of an interface between components, best to use getters. If you change the inner workings, you can adapt the getter to mimic the old behaviour and maintain compatibility.

Another reason is that you can make read-only fields. Often for DTOs, read-only and immutable is a good choice.

A third reason could be that your DTO needs to be a javabean because you intend to use it in some tool that requires it.

If none of these properties go for you, there's no reason not to use public fields.

Don't expect much of a performance difference though :)

Answer 2

I do not think it terribly bad practice to have a 'settings' or 'theme' or 'style' class with public attributes.

Modern IDEs with refactoring tools make it trivial to promote an attribute to getter/setter if you want to do any complicated calculations or checks on values at set-time.

Often in your 'setTheme' or whatever function that consumes these settings classes is a good clean place to do validation.

When setting settings like this it is usually appropriate to do a deep copied object rather than retaining a reference to a mutable class.