Each Private Static Method Is a Candidate for a New Class

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

У вас есть частные статические методы, которые помогают разбить алгоритмы на более мелкие части? У меня есть. Каждый раз, когда я пишу новый метод, я понимаю, что он может быть новым классом. Конечно, я не превращаю все из них в классы, но это должна быть цель. Частные статические методы не могут быть повторно использованы, в то время как классы могут. Вот основное отличие между ними, и это очень важно.

Вот пример простого класса:

Есть явное дублирование кода, верно? Самый простой способ его устранить - ввести частный статический метод:

Выглядит намного лучше сейчас. Но что произойдет, если у нас будет еще один класс, который нуждается в точно такой же функциональности? Мы будем вынуждены копировать и вставлять этот закрытый статический метод encoded() в него, верно?

Более лучшей альтернативой будет создать новый класс Encoded, который реализует функциональность, которой мы хотим поделиться:

And then:

class Token {
  private String key;
  private String secret;
  String encoded() {
    return "key="
      + new Encoded(key)
      + "&secret="
      + new Encoded(secret);
  }
}

Теперь эта функциональность является 1) многоразовой и 2) проверяемой. Мы легко можем использовать этот класс «Encoded» во многих других местах и можем создать для него модульный тест. Раньше мы не могли сделать это с помощью приватного статического метода.

Понимаете суть? Правило, которое я уже для себя выработал, заключается в том, что каждый приватный статический метод является идеальным кандидатом для нового класса. Вот почему в EO их вообще нет.

Кстати, публичные статические методы - это другая история. Они тоже плохи, но по другим причинам.

P.S. Теперь я думаю, что причины, указанные в этой статье, применимы к всем приватным методам, а не только к статическим.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-27 at 13:59