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.)
How to design functions when they need to work with normalized and non-normalized data
design patterns;language agnostic;functions