We can split the method in three distinct sections with three distinct purposes

public bool Login(string username, string password) {
// find the user object
var user = userRepo.GetUserByUsername(username);
if(user == null)
return false;

// validate the user login
if (loginValidator.IsValid(user, password))
return true;

// apply the login failures’s business logic
user.FailedLoginAttempts++;
if (user.FailedLoginAttempts >= 3)
user.LockedOut = true;

return false;
}

The user object can be passed as an argument (so that the Login method can be more easely tested without mock/stub), the caller can retrieve the user object from the repo, and the repo can return a NotFoundUser (null object pattern) which should fail all the login validation

The last section smells like “Feature Envy”, maybe the ‘user’ should deal with the login failures’s business logic

public bool Login(User user, string password) {
if (loginValidator.IsValid(user, password)) {
return true;
}
user.FailedLogin();
return false;
}

Last steps:
- We can/should inline loginValidator.isValid or move it to this class
- ‘Login’ seems to me more a ‘do’ method then a ‘query’ method

In the end, something like this

public void Login(User user, string password) {
if (IsNotTheUserPassword(user, password)) {
user.FailedLogin();
throw new LoginFailedException(user, password);
}
}

Sorry for my bad english

http://elegantcode.com/2008/10/06/refactoring-exercise-the-single-responsibility-principle-vs-needless-complexity/

Let me know what you guys think.

Now, we’re working on bringing everyone’s knowledge of good OO design up a notch or two, but it’s going to take time. For now, we know for certain that some parts of our application are going to change, so Mike and I worked for a while to come up with a good solution that just applied to those parts of the app. We cut the object diagram down by about 80% and STILL had a flexible solution that solved all the problems that we knew (or suspected) would change. When we went back to the developers, they were MUCH more receptive.

What gets me is that Mike knows better. We’ve been doing a great job with agile practices for about six months now, and Mike knows (or should know) not to design his application for some far off, grandiose idea of what could be a year or two down the road. Chances are that 95% of the flexibility provided by the initial design would never be needed.

There is a quote along the lines of “being made a fool of the first time is OK” subsequent time not so

i.e. wait until a scenario occurs that suggests you need to add in some extra flexibility rather than assume it needs it upfront

Actually, Uncle Bob’s PPP book discusses this very topic in greater detail in the Agile Design / OCP chapters, i believe, under the topic of “taking the first bullet”.

http://anydiem.com/2008/10/05/needless-complexity-and-taking-the-first-bullet/

I’d say the second any change came up that involved any more complexity in how failed login attempts are calculated or reset, refactor that into a separate class somehow.

Also, the hard-coded ’3′ might need to become configurable — also an excuse to refactor this part.