5

I am having trouble reconciling the Single Responsibility Principle with encapsulation. It seems like splitting responsibilities amongst classes requires exposing a lot of data. As an example, consider some object called DataPoints. DataPoints is filled with x and y coordinates, among other things. I can create a Generator class that fills DataPoints. Now, let's say I want to plot those data points. Clearly, that's a separate responsibility that might come from a class called DataPointsPlotter. But to plot the data, I need to know what the internal x and y coordinates are. With a single class handling both, that's no problem. x and y are internal variables, but both a create() and a print() method have access to those. I can expose x and y (perhaps through getters/setters--ugh) or I can pass the DataPoints structure to the Plotter class, but it still needs to get inside to get x and y. I can have an instance of Plotter declared in the DataPoints class to which I send x and y. But that's still an exposure.

How can I in this example plot x and y using the plotter without violating encapsulation?

Fadecomic
  • 1,220
  • 1
  • 10
  • 23
  • 2
    Anyone care to explain the downvotes here? As far as I can tell, I've asked a direct, answerable question with researched terms and even an example. – Fadecomic Nov 21 '12 at 14:20
  • Single downvotes without explanation can often be considered statistical noise. Someone didn't like something about the post, but since it's not obvious it can be ignored. – Adam Davis Nov 21 '12 at 17:33

1 Answers1

3
class DataPoint {

    protected x, y

    public function construct(theX, theY) {
        x = theX
        y = theY
    }

    public function getX {
        return x
    }

    public function getY {
        return y
    }

}

This encapsulates the responsibility of representing a datapoint in a known format. Assuming there's also some sanity checking going on to confirm that x and y have good values, this is one responsibility which is being encapsulated here.

class Plotter {

    public function plot(DataPoint dp) {
        x = dp.getX
        y = dp.getY

        ... plot ...
    }

}

The plotter accepts an instance of DataPoint and plots it. That's also one responsibility: plot an instance of DataPoint. It does not require Plotter to have any knowledge of the internal structure of DataPoint. It just requires a defined and stable interface how Plotter can get the necessary data from DataPoint. Which are the getters getX and getY. You can change the internals of DataPoint around however you want as long as its interface stays the same. And the responsibility of DataPoint is to hold a datapoint and give other code access to its data in a defined way. If there was no way to get data out of DataPoint, its existence would be quite useless.

So no, SRP and encapsulation are not at odds with each other. You just need to be clear about what exactly the responsibility is.

deceze
  • 510,633
  • 85
  • 743
  • 889
  • Right, I know I could use getters and setters (I mentioned them in my original question), but I find them uncomfortable. To me, they seem to violate the principle of Tell, Don't Ask. Without SRP, no getters/setters are required, because I tell the class to plot, and no one else ever has to know about x and y, regardless of getters/setters. Are SRP and Tell, Don't Ask at odds? – Fadecomic Nov 20 '12 at 16:24
  • Ah, it just struck me how this all works. I don't need to avoid having other methods in my class. I just need to avoid implementing them there. E.g. `draw` could be a method, but it accepts a `DataPointDrawer` object as an argument. That way, the responsibilities are separated amongst classes, and the data is encapsulated. There was good advice here: http://stackoverflow.com/a/5788248/429596 – Fadecomic Nov 20 '12 at 16:59
  • Well, it depends what you want your classes to do. A typical responsibility of a class like `DataPoint` would be to simply store values in a *defined format*. Its the responsibility of the class to make sure it contains valid values, but no more. Then of course it needs to allow other code to access those values, otherwise it's quite pointless. For that it needs to have a defined *interface*, for which methods are good. Maybe your language also allows properties to be accessed like methods, i.e. syntactic sugar. – deceze Nov 20 '12 at 18:03
  • You *could* add a method `public plot(Plotter p)` to your `DataPoint` class, pass a plotter to the `DataPoint` object, and have it invoke the plotter and pass it its values. That's very complicated though and means the `DataPoint` now also needs to know how to use a `Plotter`. That's totally outside its responsibilities. And you need to define an interface for it too, the `plot(Plotter p)` method. Either way you need interfaces. The more generic thing to do then is to allow *any* other class to get data out of `DataPoint` in a defined way. – deceze Nov 20 '12 at 18:06
  • Good point. Makes me wonder if `DataPoint` itself is the design flaw, then. – Fadecomic Nov 20 '12 at 19:21