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