As we know, The SRP states that every class should have single responsibility and that responsibility must be entirely encapsulated by the class.
But setters and getters do serve another responsibility – they do abstract class property(data) access.
if Setters and getters do abstract class property access, then they do serve another responsibility.
So if I have something like this,
class Config
{
private location;
public function write(array $data)
{
....
}
public function read($key)
{
...
}
public function exists($key)
{
...
}
public function delete($key)
{
...
}
// Below comes property abstraction
// Here I doubt - I CANNOT USE this class without them
// but they seem to break the SRP at the same time!?
public function setFileLocation($location)
{
$this->location = $location;
}
public function getFileLocation()
{
return $this->location;
}
public function setConfigArray(...)
{
...
}
public function getConfigArray()
{
...
}
}
I do break the SRP. The problem is that, that’s the only way class may exists.
So the question is,
In my situation, it’s almost impossible to avoid setFileLocation() and getFileLocation() methods with CRUD ones.
So if by combining CRUD methods with Data Access abstraction I do break the SRP,
Is there any way I can adhere the SRP
and keep the common concept of the Config class (CRUD operations) at the same time?
3
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.
There are two distinct levels at which you can apply the SRP.
The first level is the level of individual functions/methods. Each should do only one task (and judging by the method names, none of the methods of Config break the SRP).
The second level is the level of a class. Here the concept of a single responsibility becomes a bit more abstract, but a good indicator is if you can state the responsibilities of a class in one sentence without the (implied) use of the word and. If you can do that with the presence of the getters and setters, then the class does not break the SRP.
In general, getters and, to a lesser extent, setters are, however, an indication that the encapsulation of a class is broken.
In the case of the Config class, the setFileLocation method is good, as Config needs some way to get to know where the data is located, but the others seem suspect, because they expose information that users of Config should not have a need for.
Your config class has the responsibility of tracking configuration, which is implements by holding private references to certain data, and providing access to them through mutator methods. This does not break the SRP, because the class itself still has a single responsibility; the mutators simply help it accomplish that responsibility by abstracting access to the data. The mutators don’t have a separate responsibility from that of the class; they are a part of the greater responsibility of the class.