How to design functions when they need to work with "normalized" and "non-normalized" data

Question

I'm working on a web application that stores identifiers, such as usernames and email addresses in a "normalized" form and a "non-normalized" forms, for a variety of reasons. For example, an username 'John_Smith' would be normalized to 'johnsmith'.

However, some of the user interfaces need to work with the normalized representation, the others don't need to do so. Continuing with the same example, a visit to the page /user/John_Smith, /user/johnsmith or /user/jOhnsMith should return the same information, so normalization would be necessary. On the other hand, an API endpoint (e.g. /api/update/?user=John_Smith&value=20) wouldn't need to do that.

Thus, in the codebase, there are some functions that normalize usernames, and others that dont:

class UserManager {
  getUserInfo(username) {
    normalized_username = normalize(username)
    // do stuff with the normalized value
    return info
  }

  updateValue(username, amount) {
    // do stuff, without normalization
    return info
  }

  // ...
}

This seems very inconsistent, is there a better way?

The only better way I could think of is to require that the callers normalize the function arguments before passing them, and have all the functions work solely on such normalized inputs. (It would kill the API-strictness though, however, that is not an important requirement.)

_{(I'm aware of the real problem; it is the fact that Entity classes do not exist in the codebase. Had they been there, it would be simply a matter of Users.find('username', input_user) or Users.find('normalized_username', normalize(input_user)). However, writing a database-to-class mapper is not really possible at this point of time.)}

Answer 1

I would recommend wrapper classes around the strings, so you have NormalizedName and NonNormalizedName classes wrapping a string. This way you avoid mixing them up, and the function signatures will clearly signal what version they expect.

I would also recommend to exclusively use the NormalizedName in the business logic.

Answer 2

When I have something that could be represented in multiple forms, I generally keep one settable property, and expose another property for the different format (usually I do this in terms for names, such as CommonName, FormalName, etc):

class User
{
    public string UserName { get;set;}
    public string NormalizedName {
        get {
            return normalize(Username);
        }
    }   
}

then use it like so:

var user = new User(username)
// do stuff with user.Username (non-normalized, as-is)
// do stuff with user.NormalizedName

With that said, Robert's mention of using an ID is spot on.