On 29 Jul 2013, at 12:12, Phil Kershaw <[email protected]> wrote:
> Then pass the User to a Validator Object. Whether the validator validates > against the username is irrelevant since the username may be used elsewhere. I wrote it this way at first, then I refactored to validate before creating the User. It simplified the code a lot, as the it no longer has any steps that do nothing but pass the object along to a later stage. I've not yet found any value in putting it back to the other way. It seemed relevant to know that the username is validated in this situation, because I don't want a User to be created with a useless username. Creating either an invalid (eg 1000-character) username or a duplicate username would cause problems later on. > The point being, in my opinion, the User object should be made up of > everything that describes a User (i.e. username is this and/or user can do > this/that). I've found getting the right level of cohesion in User objects can be quite hard. I've seen User classes in apps that contain almost as much code as the rest of the app put together. It's useful to keep "user can do this/that" together, but again, I couldn't find a reason why the User needs to know its own username to do this. -- http://www.patchspace.co.uk/ http://www.linkedin.com/in/ashmoran -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/nwrug-members. For more options, visit https://groups.google.com/groups/opt_out.
