Using the “Single Responsibility Principle” forces my containers to have public setters

Question

I\'m trying hard to design following the SOLID principles. What I\'ve found is that when you use the \"Single Responsibility Principle\" (the S of SOLID) you usually have to spl

Answer 1

I definitely agree with you that sometimes you run into this problem. I've experienced it with serialization, which is similar to ORM. In my case I needed to write the state of an object to a (binary) file.

In some cases it can be appropriate to create an interface through which the internal state can be written and read. So your person class would get two metheds "save" and "load" (or "write" and "read" or whatever you think is appropriate). These methods are passed a "IPropertyWriter" and "IPropertyReader" respectively. (In my case I called them InStream and OutStream).

Person::save(IPropertyWriter writer) would then do

writer.writeProperty("name", this.name);
writer.writeProperty("age", this.age);

You can argue that you are still violating the Single Responsibility Principle, but I'd argue that nobody else should know the internals of Person. (Especially in my case of Serialization, I had to store the internal state which is partly not accessible through getters). The main point is that Person is not coupled to any Database code. Your IPropertyWriter can be everything. Furthermore, the responsibility for "knowing its own properties" is not really a new property but is attached to every object anyways.

You might also ask the question how likely it is that Person will change. If it's very unlikely, I think friend classes like in C++ are a good way, but if it's likely to change, I'd rather have the serialization methods right at the place where the properties are declared so you don't forget to update the dependent code.