Есть ли у вас частные статические методы, которые помогут вам разбить ваши алгоритмы на более мелкие части? Я делаю. Каждый раз, когда я пишу новый метод, я понимаю, что это может быть новый класс. Конечно, я не делаю уроки из всех, но это должно быть целью. Частные статические методы не могут быть повторно использованы, в то время как классы — это основное различие между ними, и оно имеет решающее значение.
Мастер (2012) Пол Томас Андерсон
Вот пример простого класса:
|
01
02
03
04
05
06
07
08
09
10
|
class Token { private String key; private String secret; String encoded() { return "key=" + URLEncoder.encode(key, "UTF-8") + "&secret=" + URLEncoder.encode(secret, "UTF-8"); }} |
Существует очевидное дублирование кода, верно? Самый простой способ решить эту проблему — ввести закрытый статический метод:
|
01
02
03
04
05
06
07
08
09
10
11
12
13
|
class Token { private String key; private String secret; String encoded() { return "key=" + Token.encoded(key) + "&secret=" + Token.encoded(secret); } private static String encoded(String text) { return URLEncoder.encode(text, "UTF-8"); }} |
Выглядит намного лучше сейчас. Но что произойдет, если у нас будет другой класс, которому нужна точно такая же функциональность? Нам придется скопировать и вставить этот закрытый статический метод encoded() в него, верно?
Лучшей альтернативой было бы введение нового класса Encoded который реализует функциональность, которой мы хотим поделиться:
|
1
2
3
4
5
6
7
|
class Encoded { private final String raw; @Override public String toString() { return URLEncoder.encode(this.raw, "UTF-8"); }} |
А потом:
|
01
02
03
04
05
06
07
08
09
10
|
class Token { private String key; private String secret; String encoded() { return "key=" + new Encoded(key) + "&secret=" + new Encoded(secret); }} |
Теперь эта функциональность 1) многоразовая и 2) тестируемая. Мы можем легко использовать этот класс, Encoded во многих других местах, и мы можем создать для него модульный тест. Мы не могли сделать это с помощью частного статического метода раньше.
Видишь смысл? Практическое правило, которое я уже понял для себя, заключается в том, что каждый частный статический метод является идеальным кандидатом для нового класса. Вот почему у нас их вообще нет в EO .
Кстати, публичные статические методы — это отдельная история. Они тоже злые, но по разным причинам .
Вы можете также найти эти связанные сообщения интересными: Поведение объекта не должно быть настраиваемым ; Могут ли объекты быть друзьями? ; Может быть только один первичный конструктор ;
| Ссылка: | Каждый частный статический метод является кандидатом на новый класс от нашего партнера по JCG Егора Бугаенко в блоге About Programming . |