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 objects, domain objects or model objects depending on the context in which they are used. The most fitting term for generic usage seems to be Data Transfer Object (DTO). This describes a POJO that only contains accessors and mutators.

I've just written one such object that contains about fifty fields used to set theme parameters on a chart. Now I'm wondering if instead of generating a hundred getters and setters I should just declare these fields as public. Doing so goes against everything my programming instincts tell me yet I can't deny that it would greatly increase my code's legibility and reduce the amount of boilerplate code in the class.

The only reason I can see not to use public fields would be if I needed to perform any sort of validation on these fields. If we assume that type validation is sufficient for my purposes, is using public fields in this scenario an acceptable break from object-oriented design? Will a public DTO perform better in large batch operations?

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.

Answer 3

There is a difference between DataStructure and Object.

Data structure should expose its innards and not behavior.

An Object should not expose its innards but it should expose its behavior, which is also known as the Law of Demeter

so, DTOs are basically Data structures. They should only expose their data, they don't need Getter and Setters. Validation is the behavior, it should not be part of DTO. It must have a different Object i.e. Validation object.

Inspired by Clean Code by Robert C. Martin(Uncle Bob)