Robert Klemme
5/28/2007 11:07:00 AM
On 27.05.2007 10:37, Peter Seebach wrote:
> In message <46593D6A.5010300@blackkettle.org>, Alex Young writes:
>> I'd use a different class method, like User.login, or some such. Then
>> you can return either a valid User instance or nil as required. If you
>> want to completely avoid exceptions, you'll either need to have a
>> #valid? method in the instance, or actually do the credential validation
>> at the class level (which seems slightly wrong to me, but there you go).
>
> Oh, that might be a good choice. Might even be a good case for one
> of those factory methods. :) Hadn't thought of that, but I like it.
> That might simplify some logic elsewhere.
I'd like to take that a bit further. I see two major aspects here:
"initialization" and "login". "Initialization" of course includes
creating an instance of class User and probably also fetching its state
from some persistent location (file, database). Ideally this is done by
some persistence framework.
"Login" is an application level concept. A user logs into an
application. Part of this is creation of some form of session as a
result of a successful login (be it a GUI object or some form of web
application session). An important part of the login process is
verification of the credentials the human user provides.
Now it depends on your application and how you model this. For example,
your class User might be purely model or application aware. Both have
their pros and cons ("model" is more flexible and has cleaner separation
of concerns, "application" might be easier and less code).
One "clean separation" solution would be to have a class User with a
method #password_ok? or something that accepts whatever the human user
provides and returns a boolean result indicating that the credentials
were ok or not. Instantiation is probably done via querying some form
of persistence framework (e.g. db_session.query_user(:login=>"pseeb").
#login is probably a method in some application class that combines
fetching the user and then verifying the password.
Of course there's a ton of ways to implement that. But IMHO it's useful
to make oneself aware of all the aspects involved here. Also it made a
nice example of the kinds of reasonings I like to apply to those cases. :-)
Kind regards
robert