Do generic Helper/Utility classes hurt the Single Responsibility Principle (SRP)?

Question

The classes Helper/Utility with generic methods, which are used for various purposes, violate the Single Liability Principle (SRP)?

The following is an example of some methods in the class:

function get_qtd_dia_mes(pDT_BASE date) return number;
function get_numero_aleatorio return number;
function get_nr_matricula_fake(pNR_MATRICULA_ORIGINAL number) return number;

Answer 1

If well done no, on the contrary, it is a way of separating a responsibility that should not be in a normal class and even more, if used in the right way, can become more DRY that for me is the most important principle to follow.

Some people are against because it hurts this or that, but what doesn’t hurt something actually helps in the software? It has algorithms that you should apply to several objects or a specific one but should not be part of the class precisely because it is utilitarian, and for what you are doing no matter the state. The question makes it clear that it is something used for various purposes, how to put this into one object? It is wrong.

Even utility classes can help in modularization by leaving separate what should be separated even if.

The whole question is what to put there and what not to put. It depends on experience.

The methods posted later in editing do not help to understand, because what defines whether it has sole responsibility is the requirement and this is not in the question. Defining the right in programming is always linked to the domain, there is no universal way to do it, if it existed it would no longer need to have programmers, or it would need very few because all problems would be solved.

The answer is about hurting the SRP, if it is unsuitable for the specific case has no way to answer without knowing the problem deeply.

Answer 2

In object orientation, which I am assuming to be the case, the implementation of a method may depend on data (fields) of a given object. It may also depend on other objects, which there involves collaborations, but then it gets a little more complicated. Let’s see the simplest cases.

For example, a method getNomeCompleto() may depend on the fields primeiroNome and sobrenome of an object Pessoa (its implementation may be, for example return primeiroNome + " " + sobrenome;). It is just an example, not necessarily good but illustrative, of method implementation that depends on fields of an object. And the fields primeiroNome and sobrenome belong to whom? To a Pessoa.

Thus, it is advisable that the method be placed in the class that has the data it needs to function.

If this is not possible, then you can put it in a utility class, but instead of creating a utility class that "aggregates" miscellaneous and disconnected utility methods, you can create utility class centered on the data types that class represents.

Let’s see each of the examples cited.

function get_qtd_dia_mes(pDT_BASE date) return number;

It depends on a date. Ideally it should belong to a type Mês. By example it should belong to the type DT_BASE (that is to say, meuDtBase.getQtdDiasNoMes()), if it is not possible then it should belong to a class DateUtil/DateHelper (for example).

function get_numero_aleatorio return number;

It depends on an RNG (random number generator). It should belong to a type Random (that is to say, Random.getNextNumber()), if it is not possible then it should belong to a class RandomUtil/RandomHelper.

function get_nr_matricula_fake(pNR_MATRICULA_ORIGINAL number) return number;

Depends on NR_MATRICULA_ORIGINAL which may be a specific type or belong to a "matriculable type" (Estudante for example). If it is not possible to belong to one of these types then it should belong to the Util/Helper correspondent.

The principle of One Responsibility has to do with cohesion, and it is in this spirit that I leave the above suggestions.