Чи застосовується Принцип єдиної відповідальності щодо функцій?

За словами Роберта К. Мартіна, СРП стверджує, що:

Ніколи не повинно бути більше ніж одна причина для зміни класу .

Однак у своїй книзі « Чистий код» , глава 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 визначений для класів, але виявляється, це також застосовно до функцій. По-друге, як така функція має декілька причин для зміни ? Я бачу, як це змінюється лише через зміну працівника.

Однією часто пропущеною деталлю Принципу єдиної відповідальності є те, що "причини змін" групуються за суб'єктами, що застосовують справи (ви можете ознайомитися з повним поясненням тут ).

Отже, у вашому прикладі calculatePayметод потрібно буде змінювати, коли потрібні нові типи працівників. Оскільки один тип співробітників може не мати нічого спільного з іншим, це було б порушенням принципу, якщо ви тримаєте їх разом, оскільки зміна вплине на різні групи користувачів (або суб’єкти використання випадків) у системі.

Тепер про те, чи застосовується принцип до функцій: Навіть якщо у вас є порушення лише в одному методі, ви все одно змінюєте клас з більш ніж однієї причини, тому це все-таки порушення SRP.

На сторінці 176, Глава 12: Надзвичайна ситуація, у розділі під назвою Мінімальні класи та методи книги дещо виправлено, зазначивши:

Прагнучи зробити наші класи та методи невеликими, ми могли б створити занадто багато крихітних класів та методів. Таким чином, це правило дозволяє припустити, що ми також підтримуємо низькі функції та кількість класів

і

Високий рівень класів та методів іноді є результатом безглуздого догматизму.

Очевидно, що він говорить про догматизм у дотриманні СРП, щоб зруйнувати ідеально дрібні невинні маленькі методи, як calculatePay()вище.

Коли містер Мартін застосовує SRP до функції, він неявно розширює своє визначення SRP. Оскільки SRP є специфічним для OO формулюванням загального принципу, і оскільки це гарна ідея при застосуванні до функцій, я не бачу з цим проблеми (хоча це, можливо, було б непогано, якби він явно включив її до визначення).

Я не бачу більше однієї причини змінитись, і не вірю, що думка про СРП з точки зору "обов'язків" або "причин для зміни" є корисною. По суті, те, що SRP отримує, це те, що програмні об'єкти (функції, класи тощо) повинні робити одне і робити це добре.

Якщо ви поглянете на моє визначення, воно не менш розпливчасте, ніж звичайне формулювання СРП. Проблема звичайних визначень СРП полягає не в тому, що вони занадто розпливчасті, а в тому, що вони намагаються бути занадто конкретними щодо чогось суттєво розпливчастого.

Якщо ви подивитеся на те, що calculatePayробить, це однозначно робить одне: відправлення на основі типу. Оскільки у Java є вбудовані способи здійснення диспетчеризації на основі типу, calculatePayце неелегантно і не ідіоматично, тому її слід переписувати, але не з вказаних причин.

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

Заява "причина зміни" іноді трохи вводить в оману, але якщо ви змінюєте calculateSalariedPayабо calculateHourlyPayперелічуєте Employee.typeцей метод, ви повинні змінити цей метод.

У вашому прикладі функція:

• перевіряє тип працівника
• називає іншу функцію, яка розраховує гроші відповідно до типу

На мою думку, це не є безпосередньо порушенням SRP, оскільки випадки комутації та дзвінки не можуть бути написані коротше, якщо ви думаєте про Співробітника та методи вже існують. У будь-якому випадку це чітке порушення відкритого закритого принципу (OCP), оскільки ви повинні додавати заяви "case", якщо ви додаєте типи службовців, тому це погана реалізація: refactor.

Ми не знаємо, як слід розраховувати "Гроші", але найпростіший спосіб - це мати Employeeінтерфейс і деякі конкретні реалізації з getMoneyметодами. У цьому випадку вся функція непотрібна.

Якщо його складніше обчислити, можна використовувати шаблон відвідувача, який також не є 100% SRP, але це більше OCP, ніж вимикач.