Is it necessary to have getters and setters in POJO's [duplicate]

Question

I have been going through clean code book which states that the class should not expose the internal state of its data and only should be exposing the behavior. In case of a very simpl and dumb java bean exposing the internal state which getter's and setters, is it not worth just removing them and make the private members public? Or just treat the class as a data structure?

Answer 1

I don't think so. It depends of the lifetime of your Object and its "exposure" (external modification).

If you're only using it as a data structure, exposing fields in secure way (final) sounds enough:

public class Person {
    public final String firstName;
    public final String lastName;

    public Person(String firstName, String lastName) {
        this.firstName = firstName;
        this.lastName = lastName;
    }
}

Answer 2

The definition of POJO doesn't mandate getter/setter.

Experimentally, I am not using getter and setter in my current project.

The approach I am taking is this one:

unless necessary, don't provide getter/setter.

So far, I didn't find a case where I really needed get/set.

Some friend told me: "having get/set is helpful if in the future you need xyz"; my reply has been: when -in the future- I need to do so, I will provide the getter and setter; I don't want to anticipate anything.

The objection about incapsulation, that some may raise, is not really a valid one: providing getter and setter breaks incapsulation in the same manner, plus you have additional lines of (useless) code. Bugs may also lay in getter and setters.

This is an example of one of a non-trivial domain class:

public class SSHKey implements IsSerializable {
    public Long id;
    public Long userId;
    public String type;
    public String bits;
    public String fingerprint;
    public String comment;

    @SuppressWarnings("unused")
    private SSHKey() { // required by gwt-rpc
    }

    public SSHKey(String text) throws InvalidSSHKeyException {
        Ensure.that(text != null, new InvalidSSHKeyException("Invalid Key"));
        text = text.trim();
        String[] parts = text.split(" ", 3);
        Ensure.that(parts.length >= 2,
                new InvalidSSHKeyException("Invalid Key"));

        type = getType(parts);
        Ensure.that(type.equals("ssh-rsa") || type.equals("ssh-dss"),
                new InvalidSSHKeyException(
                        "Key must start with 'ssh-rsa' or 'ssh-dss'"));
        bits = getBits(parts);
        comment = getComment(parts);
    }

    private String getBits(String[] parts) {
        return parts[1];
    }

    private String getComment(String[] parts) {
        if (parts.length == 3)
            return parts[2];
        return type + " " + bits.substring(0, min(15, bits.length())) + "...";
    }

    private String getType(String[] parts) {
        return parts[0];
    }
}

The constructor takes the responsibility to validate and prepare the data to be manageable. Thus this logic doesn't need to be in a setter/getter.

If I was shown object with public members some years ago, I would probably not like them; maybe I am doing something wrong now, but I am experimenting and so far it is ok.

Also, you need to consider if your class is designed to be extended or not (so, foresee the future is part of the requirements), and if you want your object to be immutable. Those things you can only do with get/set.

If your object must be immutable, and you can avoid the empty constructor, you can just add 'final' to the member instances, btw. Unfortunately I had to add IsSerializable (similar to java.io.Serializable) and an empty constructor since this is required by gwt. So, you could tell me then "you see? you need the getter an setter"; well not so sure.

There are some jdbc frameworks which promote the use of public fields btw, like http://iciql.com This doesn't imply that this project is correct, but that some people are thinking about it.

I suppose that the need of getter/setter is mostly cultural.