Применим ли принцип единой ответственности к функциям?

По словам Роберта К. Мартина, SRP заявляет, что:

Никогда не должно быть более одной причины для изменения класса .

Однако в своей книге « Чистый код» , глава 3: Функции, он показывает следующий блок кода:

    public Money calculatePay(Employee e) throws InvalidEmployeeType {
        switch (e.type) {
            case COMMISSIONED:
                return calculateCommissionedPay(e);
            case HOURLY:
                return calculateHourlyPay(e);
            case SALARIED:
                return calculateSalariedPay(e);
            default:
                throw new InvalidEmployeeType(e.type);
        }
    }

И тогда говорится:

Есть несколько проблем с этой функцией. Во-первых, он большой, и когда добавляются новые типы сотрудников, он будет расти. Во-вторых, это очень четко делает больше, чем одно. В-третьих, он нарушает принцип единой ответственности (SRP), потому что есть несколько причин для его изменения . [Акцент мой]

Во-первых, я думал, что SRP был определен для классов, но оказалось, что он также применим к функциям. Во-вторых, как эта функция имеет более чем одну причину для изменения ? Я могу видеть только его изменение из-за изменения на сотрудника.

Одна часто пропускаемая деталь принципа единой ответственности состоит в том, что «причины изменений» сгруппированы по субъектам прецедента (полное объяснение вы можете найти здесь ).

Итак, в вашем примере calculatePayметод нужно будет менять всякий раз, когда требуются новые типы сотрудников. Поскольку один тип сотрудника может не иметь ничего общего с другим, это будет нарушением принципа, если вы будете держать их вместе, так как изменение затронет различные группы пользователей (или участников варианта использования) в системе.

Теперь о том, применим ли этот принцип к функциям: даже если у вас есть нарушение только в одном методе, вы все равно меняете класс по нескольким причинам, поэтому это все еще является нарушением SRP.

На странице 176, Глава 12: Появление, в разделе, озаглавленном « Минимальные классы и методы», в книге приведено несколько исправлений:

Чтобы сделать наши классы и методы небольшими, мы можем создать слишком много крошечных классов и методов. Таким образом, это правило предполагает, что мы также сохраняем низкое количество функций и классов

и

Высокие показатели класса и метода иногда являются результатом бессмысленного догматизма.

Очевидно, он говорит о догматизме в следовании SRP, чтобы сломать совершенно прекрасные невинные маленькие методы как calculatePay()выше.

Когда мистер Мартин применяет SRP к функции, он неявно расширяет свое определение SRP. Поскольку SRP является ОО-специфической формулировкой общего принципа, и, так как это хорошая идея применительно к функциям, я не вижу проблемы с этим (хотя было бы неплохо, если бы он явно включил ее в определение).

Я также не вижу более одной причины для изменения, и я не верю, что полезно думать о ПСП в терминах «обязанностей» или «причин для изменения». По сути, к чему стремится SRP, это то, что программные объекты (функции, классы и т. Д.) Должны выполнять одну задачу и делать это хорошо.

Если вы посмотрите на мое определение, оно не менее расплывчато, чем обычная формулировка SRP. Проблема с обычными определениями SRP заключается не в том, что они слишком расплывчаты, а в том, что они пытаются быть слишком конкретными в отношении чего-то, что по существу расплывчато.

Если вы посмотрите на то calculatePay, что делает, он явно делает одну вещь: отправка на основе типа. Поскольку в Java есть встроенные способы выполнения диспетчеризации на основе типов, calculatePayона неэлегатична и не идиоматична, поэтому ее следует переписать, но не по указанным причинам.

Вы правы @Enrique. Независимо от того, является ли это функцией или методом класса, SRP означает, что в этом блоке кода вы делаете только одну вещь.

Утверждение «причина для изменения» иногда немного вводит в заблуждение, но если вы измените calculateSalariedPayили calculateHourlyPayили Employee.typeваше перечисление, вам придется изменить этот метод.

В вашем примере функция:

• проверяет тип работника
• вызывает другую функцию, которая вычисляет деньги в соответствии с типом

По моему мнению, это не является прямым нарушением SRP, так как случаи переключения и вызовы не могут быть записаны короче, если вы думаете о Employee, и методы уже существуют. В любом случае, это явное нарушение принципа открытого-закрытого (OCP), так как вы должны добавлять операторы «case», если добавляете типы сотрудников, так что это плохая реализация: рефакторинг.

Мы не знаем, как рассчитывать «деньги», но самый простой способ - иметь Employeeинтерфейс и некоторые конкретные реализации с getMoneyметодами. В этом случае вся функция не нужна.

Если его сложнее вычислить, можно использовать шаблон посетителя, который также не является 100% -ным SRP, но это больше OCP, чем случай коммутатора.