SOLID Principles – Do Setters and Getters Break Single-Responsibility Principle?

single-responsibilitysolid

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?

Best Answer

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.

Related Topic