Ray Houston - All Comments

NotImplementedException and the Interface Segregation Principle

Jimmy Bogard — Sun, 12 Oct 2008 19:51:02 GMT

This week, Derrick Bailey will be in town (Austin) to talk about the SOLID principles .  One of

re: Single-Responsibility Versus Needless Complexity

Gabriele Lana — Mon, 06 Oct 2008 21:54:45 GMT

I agree with you, but in the example above IMHO the SRP should be applied

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

re: Single-Responsibility Versus Needless Complexity

Jan Van Ryswyck — Mon, 06 Oct 2008 19:35:47 GMT

I'd thought I's take this for a spin:

elegantcode.com/.../refactoring-exercise-the-single-responsibility-principle-vs-needless-complexity

Let me know what you guys think.

Elegant Code » Refactoring Exercise: The Single Responsibility Principle vs Needless Complexity

Mon, 06 Oct 2008 19:33:31 GMT

Pingback from Elegant Code » Refactoring Exercise: The Single Responsibility Principle vs Needless Complexity

re: Single-Responsibility Versus Needless Complexity

Ryan — Mon, 06 Oct 2008 12:42:44 GMT

Funny, I was having a very similar conversation with a co-worker late last week. Mike is an extremely smart developer and adheres to SOLID practices without having to think about it. He was very proud of a solution to a particularly nasty problem we've had recently, but when he presented his solution to the more junior developers on the team, it was met with a deafening silence. While his solution was EXTREMELY flexible, the junior guys just didn't get it due to it's complexity. There were simply too many relationships for the young guys to follow and they quickly became frustrated. What we had was a deer in the headlights scenario.

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.

Dew Drop - October 6, 2008 | Alvin Ashcraft's Morning Dew

Dew Drop - October 6, 2008 | Alvin Ashcraft's Morning Dew — Mon, 06 Oct 2008 12:31:49 GMT

Pingback from Dew Drop - October 6, 2008 | Alvin Ashcraft's Morning Dew

re: Single-Responsibility Versus Needless Complexity

Chris — Mon, 06 Oct 2008 07:11:44 GMT

Yeah - what sean said

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

re: Single-Responsibility Versus Needless Complexity

Sean Scally — Mon, 06 Oct 2008 03:55:17 GMT

Good points made there.

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

anydiem.com/.../needless-complexity-and-taking-the-first-bullet

re: Single-Responsibility Versus Needless Complexity

Ray Houston — Mon, 06 Oct 2008 01:25:28 GMT

@chad - yeah, I agree. The point I'm trying to make here is not to abstract just to be abstract. If you do, you'll have a lot of complexity that just ends up being waste. I've been down that road a time or two.

re: Single-Responsibility Versus Needless Complexity

chadmyers — Mon, 06 Oct 2008 00:14:33 GMT

Whomever asked about SRP had good instincts, though. That code does stick out like a sore thumb.

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.

re: How Mr. Buford got me started in software development

Kevin Miller — Wed, 24 Sep 2008 20:55:26 GMT

Great story Ray thanks for sharing this and thank you to all the Mr. Bufords of the world that work hard, get paid little and inspire the little Ray Houstons of the world.

Arjan`s World » LINKBLOG for September 24, 2008

Arjan`s World » LINKBLOG for September 24, 2008 — Wed, 24 Sep 2008 20:18:59 GMT

Pingback from Arjan`s World » LINKBLOG for September 24, 2008

re: Learning TDD

Ray Houston — Wed, 24 Sep 2008 17:37:07 GMT

@Robb - thanks for the kind praise. When you say "your blog" I'm sure you mean the whole LosTechies blog and not just mine. Either that or you have me confused with somebody else. ;)

@Duncan & @Robb - I know that several of us are going to attempt to record "something". I can't make any promises to what we'll get and the quality, but we're going to make an effort. I'll have to check out Ustream.tv too.

re: Learning TDD

Ray Houston — Wed, 24 Sep 2008 17:25:57 GMT

@c - We have other types of tests that verify the application from end to end (integration tests) which do hit the database, but for our unit tests, they do not hit the DB.

When I mentioned state based testing, what that means is that I'm verifying that the properties of my object under test are what they're expected to be after a specified operation. Interaction based testing means that I'm verifying that my object under test is calling methods and properties on its dependencies correctly. The interaction based testing makes it tough when I want to refactor the way I implemented something without changing its functionality.

re: Learning TDD

Robb Schiefer — Wed, 24 Sep 2008 16:49:46 GMT

I would love to come too, but work and family aren't flexible enough for me to take a road trip from Birmingham, AL. Granted I'm in the same country (sorry Duncan), but I might as well be across the world.

I really enjoy your blog and know the event would be hugely helpful to me as well. If you have decided not to video the event yourself, how about Ustream.tv? They will broadcast your event live and I believe archive it to watch later. All for free.

Most new laptops come with webcams and mics in them. All you would have to do is setup one of these laptops in each of the presentation rooms.

<GuiltTrip>Your blog has become an international information souce for developers. We can't all live in the greater Austin area. You owe it to your readers to make this attempt.</GuildTrip>

Regardless, thanks for all your content.