SOLID - SRP, One job or one reason for change

Question

There is a lot of confusing around the internet about the SRP.

Does SRP requires:

1. classes/functions should do one job?
2. classes/functions should have only one reason for change (and we don not care how many jobs our classes is performing, at least when we think about SRP)

eg.

Lets assume that we have one class that performs a lot of work/jobs (I know this is bad, we should not put everything into one class)

Also, lets assume that this one class serves one feature, and this feature has only one reason for change, i.e. reason for change can came only from one actor (e.g. our CTO)

Does this code still apply to SRP?

Additionally quoting Clean Architecture by Robert C. Martin

The SOLID principles, the Single Responsibility Principle (SRP) might be the least well understood. That’s likely because it has a particularly inappropriate name. It is too easy for programmers to hear the name and then assume that it means that every module should do just one thing.

Make no mistake, there is a principle like that. A function should do one, and onlyone, thing. We use that principle when we are refactoring large functions intosmaller functions; we use it at the lowest levels. But it is not one of the SOLID principles — it is not the SRP.

Answer 1

As always, it depends. "Single Responsibility" means just that, to be responsible for one thing.

The "one thing" could be a narrow or a some sort of a wide field. An simple example:

Imagine a class that calculates a cryptographic signature of a string and another class for encrypting a string. Both classes respect SRP because they each do just one thing.

If you tie them together in one class with two methods, one for encrypting a string and one for calculating the signature, you're clearly violating SRP. Because encrypting and signing are not related together.

But now imagine, you have a system which exchanges signed and encrypted strings that conform to some standard. So of course these two functions are related and one class has to handle both operations.

A client of this class even is not interested how the signing and encryption are related. A client just provides a string to be prepared for transmission and the class signs and encrypt the string. So this class of course respect SRP regardless of doing two things, signing and encrypting.

Back to your (bad) example with the class that performs a lot of work/jobs. When the jobs the class performs are related, there is a chance that SRP is respected. But when the jobs are not related, the class clearly violates SRP.