Databases and the single responsibility principle

I've always considered the single responsbility principle more of a philosophy than principle.

Robert C. Martin (Uncle Bob) restates the Single Responsibility Principle (linked to PDF):

There should never be more than one reason for a class to change

Quoted from the reply you got your post.

When we try to appease the SPR, we focus on the implementation rather than on the purpose.

Major mistake.

My understanding of the SRP is this, when an addition blurs the responsibility of an implementation, the focal point should be reconsidered.

For me, it is all about the relationships between purposes.

Sure, a user has to be authenticated and authorized regarding actions to take - but the authentication and authorization should be separated from the user.

It's not like you are going to try to authorize/authenticate a non-user anyway?

And thus, you should consider splitting implementation when the responsibilities of a class outgrows it purpose. After all, design patterns have purposes too.

Take a look at GRASP when you get a chance.

Honestly, I think you're taking the concept of single responsibility a little too far. Getters and setters are incidental to the functioning of the class whether you do it by direct access to public members or use methods (or properties) to do it.

You're making the argument that getting and setting some member of the class is a separate responsibility and should therefore be moved elsewhere. Let's say we do that, and now you have classes called Config and ConfigAccessor. At this point, you now have an air gap between the two classes, because Config has no interface to access its location member. That makes it impossible to write ConfigAccessor, and you're left with an immutable, write-once class that's of no use whatsoever. If you add some sort of interface to allow ConfigAccessor to do its job, you'll find yourself with a recursive problem.

The SRP, like many other things in this field is a principle, not a hard-and-fast rule. That means you should be applying judgement to your situation instead of trying to follow it unconditionally. There's a line between being a purist and getting the job done, and when the former is preventing the latter, you're on the wrong side of it.

If I can critique your design a bit: If your Config class is designed to be an interface between a configuration file stored on disk and your code, the last thing you want to do is change its location midstream. If you're changing the location as a way of starting access to a different file, you should be destroying the old object and creating a new one. You didn't make clear whether you intend to store the contents of the file in the object. If you'd planned to use it as a way to inhale the contents of one configuration file and write it to another, consider using a method that clones the data into a new object that points at the new file.