Преобразование метода publi c в приватный метод

Question

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

public class service() {
  public String getAuthenticatedUserName() {
    return SecurityContext.getName();
  }

  public getIdentityUserIdByUsername(String username) {
    return db.getUser(username).getId();
  }
}

, который использовался в несколько других классов как service.getIdentityUserIdByUsername(service.getUsername()), которые казались избыточными. Был создан новый метод, объединяющий два вызова.

public getIdentityUserId() {
  return getIdentityUserIdByUsername(getUsername());
}

getIdentityUserIdByUsername() все еще используется в других классах без необходимости getUsername(). Тем не менее, метод getUserName() больше не используется в других классах.

Мой пример намного проще, чем реализация, метод имеет тестовое покрытие, что немного неудобно (пересмешивать классы c без Powermock и немного googling et c). В будущем, скорее всего, нам понадобится метод getUsername(), и метод не изменится.

В обзоре кода было предложено, чтобы метод getUsername() теперь был закрытым, поскольку он нигде не вызывается остальное. Это потребует, чтобы явные тесты для метода были удалены / закомментированы, что выглядит как повторное усилие переписать или уродливо оставить закомментированный код.

Лучше ли менять метод на приватный или оставить он опубликован c, потому что он имеет явное покрытие, и он может понадобиться вам в будущем?

Answer 1

Лучше ли сменить метод на приватный или оставить его публичным c, поскольку он имеет явное покрытие и может понадобиться в будущем?

ИМО, вы задавая неправильный вопрос. Так называемая «лучшая практика» не входит в это. (Прочитайте ссылки ниже!)

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

Альтернативы:

1. Вы можете удалить тестовый пример для частного метода.
2. Вы можете закомментировать тестовый пример.
3. Вы можете исправить тестовый пример так, чтобы он работал с закрытой версией метода.
4. Вы можете оставить метод как public.

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

Наконец, я бы посоветовал избегать отклонения опций только потому, что они «пахнут кодом». Эта фраза имеет ту же проблему, что и «лучшая практика». Это заставляет вас отклонять действительные варианты, основанные на обобщениях ... и текущих мнениях (даже модных) о том, что является хорошей или плохой "практикой".

---

Поскольку вам нужно мнение другого человека ("лучшая практика") это просто мнение!), мое мнение, что все альтернативы действительны. Но мой голос должен был бы оставить метод как public. Это наименьший объем работы, и неиспользуемый метод в API приносит мало вреда. И, как вы говорите, существует разумное ожидание того, что метод будет использоваться в будущем.

Вам не нужно соглашаться с рецензентом кода. (Но это не стоит делать врагов более ...)

---

Ссылки:

• Нет лучших практик Джеймса Баха
• Не существует такой вещи, как «Лучшие практики»: вопросы контекста. Теда Ньюарда.

Answer 2

Если метод является public static, то вы можете оставить его как есть, потому что нет никакого влияния того, что он будет опубликован c. Это метод без эффекта, его экспозиция никогда не причинит никакого вреда.

Если это метод уровня объекта publi c, то -

1) Сохраните его, если он похож на API. Он имеет четко определенный ввод, вывод и предоставляет четко определенные функциональные возможности и имеет связанные с ним тесты. Публикация c ничего не вредит.

2) Сделайте его приватным, если у него есть побочные эффекты Если это приводит к тому, что другие методы ведут себя по-разному, потому что это изменяет состояние объекта, то это вредно, если публикуется c.

Answer 3

Может иметь смысл проверить частные методы. Стандартный способ сделать это, имеющий ряд преимуществ, заключается в следующем:

• Убедитесь, что тестовый код находится в том же пакете, что и код, который он пытается протестировать. Это не означает тот же каталог; например, имейте src/main/java/pkg/MyClass.java и src/test/java/pkg/MyClassTest.java.
• . Аннотируйте их с помощью @VisibleForTesting (из гуавы ), если вам нужна какая-либо запись об этом.

Отдельно от этого, пространство ввода для методов publi c (publi * 1022) * в смысле: это часть моего API и определяет точки доступа, где внешний код вызывает мой код) обычно представляет собой некоторый список точек входа ... если он у вас есть. Чаще всего такого определения нет вообще. Можно сказать, что все методы publi c во всех типах publi c неявно образуют список (то есть, что ключевое слово public подразумевает, что оно предназначено для использования внешним кодом), которое затем по тавтологии устанавливает, что любая публикация c метод имеет правильную подпись. Не очень полезное определение. На практике ключевое слово public не обязательно должно означать «это доступно через API». Различные модульные системы (такие как Jigsaw или OSGi) имеют решения для этого, как правило, позволяя вам объявлять определенные пакеты как на самом деле publi c.

С помощью такого инструментария «деревья» встряхивают ваши методы publi c для указания из того, что им больше не нужно публиковаться c, имеет смысл. Без них ... ты не сможешь этого сделать. Существует такое понятие, как «этот метод никогда не вызывается в моей кодовой базе, но он доступен для внешних абонентов; абоненты, которых у меня нет в наличии здесь, и дело в том, что это выпущено, и, возможно, есть проекты, которые еще даже не начали писать, которые предназначены для вызова этого ».

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