How to guarantee invariants / Inner logic in setter methods

Question

According to DDD-principles I use factory-methods to create consistent objects and to ensure that the objects are in the right state.

Now I'm in doubt about inner logic of setter methods. I'm tied up with an object, that's similar to the following code snippet, so let's take it as an example:

public class UserCredentials {

    private String username;

    private UserCredentials() {
        super();
    }

    public static UserCredentials create (final String username) {
        String username = username.toUpperCase();
        UserCredentials newInstance = new UserCredentials(username);
        return newInstance;
    }

    private UserCredentials(final String username) {
        this.username = username;
    }

    public String getUsername() {
        return this.username;
    }

    public void setUsername(final String username) {
        this.username = username;
    }

    public void checkConsitency() {
        ...
        isUppercase();
        ...
    }
}

We do have an invariant: The username of the credentials must always be uppercase. Now I want to make sure, that changing the username doesn't violate the invariant.

But how do I guarantee the rule?

1. I do rewrite the setter method and add the conversion logic to the setter. Drawback: Setter contains logic.

2. I rely on clients, that they always provide uppercase username and I will throw consistency exceptions in the case of violation. Drawback: Origin of the wrong usage is hard to discover, moreover its bad practice at all.

3. I remove the setter method and replace it with a domain method like changeUsername(String username) that contains the conversion logic. Drawback: external developers may miss the setter method.

Because of the statement "username of credential must always be uppercase" I tend to prefer alternative 3.

But is there a smarter solution?

Answer 1

Choose solution #1. There is nothing wrong with setters containing validation or coercion logic. In fact, that is the only reason why we'd use setters and getters instead of public member fields!

Your create factory method is also a bit awkward, as there is no reason not to use the constructor instead:

public class UserCredentials {

    private String username;

    public UserCredentials(final String username) {
        super();
        this.username = coerceUsername(username);
    }

    public String getUsername() {
        return this.username;
    }

    public void setUsername(final String username) {
        this.username = coerceUsername(username);
    }

    private static String coerceUsername(final String username) {
        return username.toUpperCase();
    }
}