Предпочитаю частные статические методы методам экземпляра

Question

У меня странная ситуация. На самом деле я впервые пробую тестировать JUnit. В течение многих лет меня учили, что статические методы не годятся (за исключением некоторых случаев).

НО

Мне показалось очень хорошим иметь в своих классах несколько статических методов. Основная причина в том, что я могу контролировать все, что входит в метод: я точно знаю, что смогу контролировать и изменять только параметры.

Любой пример будет тривиальным, на самом деле это всего лишь метод " предотвращения того, чтобы я сделал что-то не так с неправильным объектом в неправильной ситуации ", возможно, потому что я забыл, что объект должен быть то же самое с начала до конца выполнения метода. Как инкапсуляция.

Итак, я объясняю последнюю ситуацию, которая заставила меня думать так:

class Graph {
   private Set<Edge> edges;

   // {...}

   public void newEdge(Edge e) {
      edges.add(e);
      edges = simplify(edges);
   }

   private static Set<Edge> simplify(Set<Edge> input) {
      // do something
      return output;
   }
}

Разве это не:

private static Set<Edge> simplify(Set<Edge> input) {
   // do something
   return output;
}

безопаснее, чем

private void simplify(Set<Edge> input) {
   // do something
   this.edges = output;
}

Пожалуйста, скажите мне, если я злюсь. Большое спасибо

Answer 1

Опираясь на мой комментарий, как упомянул @Jason, статические методы неплохие, просто есть ситуации, когда они больше подходят.Например, раскрытие части автономной функциональности, как правило, выделяет статические методы.

Это означает, что вам нужно будет указать аргументы самостоятельно, например, метод simplify.Это на самом деле не масштабируется, и если у вас есть объект Graph, то поведение simplify может быть чем-то таким, что объект может представлять.

Это было бы внедрение зависимостивступает в игру, так как это облегчит ваши тесты.Таким образом, в вашем случае у вас будет что-то вроде:

class Graph {
    private Set<Edge> edges;

    public Graph(Set<Edge> edges) {
        this.edges = ...
    }
}

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

Answer 2

Дело не в том, что статические методы не хороши, просто в том, что они имеют определенную цель.

Прежде всего, мы говорим о закрытом методе, поэтому это не является обычным для любого кода внекласс, чтобы называть это.Поэтому только разработчик класса будет писать код для его вызова.Это означает, что менее вероятно, что он будет вызван неправильно.

Кроме того, при тестировании класса следует убедиться, что он работает так, как должен.

Во-вторых, статический метод не имеет доступа к переменным экземпляра внутри объекта.Поэтому если целью метода является чтение или изменение переменной экземпляра, то она не может быть статической.

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

Редактировать : Например:

Если у вас нет внешней необходимости выполнять упрощение:

class Graph {
    private Set<Edge> edges;

    // {...}

    public void newEdge(Edge e) {
        edges.add(e);
        simplify();
    }

    private void simplify() {
        // use this.edges as your input
        // do something
        // set the value of your output to this.edges
    }
}

Другое редактирование :

объект должен быть таким же от начала и до конца выполнения метода

Если для вас важна согласованность в многопоточной среде, вам необходимо использовать соответствующий метод синхронизации потоков - не полагайтесь только на изменение объекта в конце метода.