Уменьшение сложности метода

Question

У меня есть метод, который выполняет несколько задач.Это часть бизнес-логики приложения, но она плохо читаема из-за множества блоков if-then и try-catch и множества вызовов log.

public class MyClass {     

boolean createReport, sendReport, warnIfErrors;

public void archiveAll() {

    if (createReport) {
      //... ...
    }

    if (sendReport) {
      //... ...
    }

    if (warnIfErrors) {
      //... ...
    }

} 

Идея состоит в том, чтобы переместитьзадачи в специальные методы и имеют метод «archiveAll», который можно понять с первого взгляда:

public void archiveAll() {

    doCreateReport();

    doSendReport();

    doWarnIfErrors();

} 

Но при этом возникают две проблемы:

1. , если всеметоды используют локальную переменную, я переместу ее как поле класса, но это не очень хороший дизайн
2. Я хочу переместить тест if (createReport) в метод doCreateReport тоже, потому что часть сложностивытекает из испытаний, которые сделаны.Это делает вспомогательные методы плохо связанными.

Answer 1

Если у вас есть много локальных переменных, которые разделяются между ними, может иметь смысл создать закрытый класс для хранения их вместе, возможно, даже сделать что-то вроде:

MyReport report = new MyReport(); // or MyReport.doCreateReport(); if it makes more sense
report.send();
report.warnIfErrors();

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

Если вы можете обойтись просто передачей этих общих переменных в качестве параметров, не имея огромных списков параметров, сделайте это.

Answer 2

1. Вы также можете передать необходимые данные в качестве аргументов в методы.
2. Я бы сделал проверку перед вызовом метода. Если метод называется doCreateReport, он должен на самом деле сделать , что.

Answer 3

1. Вместо того, чтобы создавать поля класса переменных, просто параметризуйте функцию и передайте значения.Это имеет еще одно большое преимущество: ваш код теперь станет более тестируемым модулем.Я всегда рекомендую, чтобы каждый метод был настолько независимым, насколько это возможно в UT.
2. Если вы изменили имя на checkAndCreateReport, вы все равно будете думать так: