Did I understand the principle of one responsibility in a class correctly?

Question

Programming

Reading the book Freeman and Freeman. Design patterns saw a cool principle: "A class should have only one reason to change" is page 361 in the book.

I would like someone to check the course of my thoughts and point out my errors in reasoning so that I can understand how correctly I understood this principle.

Let's take the simplest class as an example:

class CustomFormat
{
public:
  Header1 getHeader1();
  std::vector<Header2> getHeader2Array();
  void load();
  void save();  
};

It seems to me that the main task of the class is to provide methods for working with header values. But it also has an additional task: the class has read/write methods.

Question: Do I understand correctly that if we follow this principle, then we should transfer the load\save methods to another class, for example, to some CustomFormatSerializer thread?

I'm not interested in words like: "You know in practice ...". It is the question of following this principle that worries me very much, and not possible compromises to achieve tasks in practice.

Answer 1

It seems to me that the main task of the class is to provide methods for working with header values. But it also has an additional task: the class has read/write methods.

If you follow this logic to the end, then the load and save methods fully comply with this semantics, because load changes (loads) the headers, and save saves them. Those. in this problem setting, load/save are methods of CustomFormat deservedly.

Answer 2

It seems to me that the main task of the class is to provide methods for working with header values.
You should not think that the class is created to solve a specific problem, and the developer should understand and not guess.
It is the question of following this principle that worries me very much
. Really “very”? This, pardon my French, bullshit bothers you ?
If, in essence, the answer is “yes”, in order to follow the indicated principle, serialization must be taken outside the class.
If we follow another principle , then serialization should be considered as an auxiliary function for solving the main task, therefore it is not necessary to take it out.

Answer 3

As far as I understand, it depends on the depth of task splitting. For example, the task is to make a simple drawing. You can put everything in a class like CPaintBox. But you can break this big task into several smaller ones - working with a brush, loading, saving, applying filters. Working with a brush can also be divided into working with the shape of a brush and working with its color.

Answer 4

If there are several formats, then yes, it’s worth moving to another class. And work at an abstract level through interfaces.
On idea the class should work only with fields (properties). So it depends a lot on the purpose of the save/load methods

Answer 5

en.wikipedia.org/wiki/Single Responsibility Principle