If you said does a Person needs to know their name, I'd assume you would
say 'yes'. So whats different about a user knowing their name. Some things
that come to mind are:

- A User is not a Person, its more some sort of Account construct that has
a person.

- A username is not the name of a user, otherwise why not User.name instead
of User.username. Perhaps its an unique_account_identifier or something
equally unwieldy.

The common (almost idiomatic) way of using user/username means that we can
talk about accounts, logins and users in a very person centric way - which
is probably a good thing in most cases.

ObjectModelling probably has to make compromises like this because the
words used for identifying Object/Classes are required to have a unique and
clear definition within in a program. However in natural language they have
a range of definitions that can be nuanced by context.

tx for the provocation to think




On 29 July 2013 22:21, David Workman <[email protected]> wrote:

> Chiming in a little late, but oh well :)
>
> I'd say that no, you don't need to keep the username around. The username
> is an authentication artifact used to locate a particular identity, not
> part of the identity that the User represents. Obviously, the username
> could be dual-purposed as part of this identity (in the form of greetings,
> display name, etc.) but that role could just as easily be fulfilled by a
> display_name attribute that defaults to the username in the persisted data.
>
> Dave W
>
>
>
> On 29 July 2013 17:04, Kevin Rutherford <[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.
>>
>> What if your objects had to be immutable?  Would that lead to a
>> validation pipeline containing objects such as CandidateUser,
>> ValidatedCandidate, UserAccount etc? And if so, where do the factory
>> methods for each of those types live?
>>
>>
>> --
>> http://xpsurgery.com -- remote one-to-one tutoring in TDD and OO
>> http://kevinrutherford.co.uk -- software development coaching
>> http://refactoringinruby.info -- Refactoring in Ruby, the book
>>
>> --
>> 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.
>>
>>
>>
>  --
> 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.
>
>
>



-- 
------------------------
Andrew Premdas
blog.andrew.premdas.org

-- 
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.


Reply via email to