將公共方法轉換為私有方法

Question

我最近重構了一些代碼，這些代碼將一個僅與另一個公共方法結合使用的公共方法轉換為一個調用。

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()方法。

我的示例比實現簡單得多，該方法的測試覆蓋率有點難做（模擬沒有 Powermock 的靜態類和一些谷歌搜索等）。 將來我們很可能需要getUsername()方法，並且該方法不會改變。

在代碼審查中建議getUsername()方法現在應該是私有的，因為它不會在其他任何地方被調用。 這將需要刪除/注釋掉該方法的顯式測試，這似乎需要重復重寫或留下注釋掉的代碼。

將方法更改為私有還是公開是最佳實踐，因為它具有明確的覆蓋范圍並且您將來可能需要它？

Answer 1

將方法更改為私有還是公開是最佳實踐，因為它具有明確的覆蓋范圍並且您將來可能需要它？

海事組織，你問錯了問題。 所謂的“最佳實踐”並沒有涉及。 （閱讀下面的參考資料！）

真正的問題是哪種替代方案最有可能最適合您。 這真的由你來決定。 不是我們。

替代方案是：

1. 您可以刪除私有方法的測試用例。
2. 您可以注釋掉測試用例。
3. 您可以修復測試用例，使其與該方法的私有版本一起運行。
4. 您可以將該方法保留為public 。

要做出合理的決定，您需要考慮每種替代方案的技術和非技術利弊......在您的項目背景下。 但是不要太擔心做出錯誤的決定。 從大局來看，做出錯誤的選擇會產生嚴重后果的可能性很小。

最后，我建議避免僅僅因為選項是“代碼異味”而忽略選項。 該短語與“最佳實踐”具有相同的問題。 它會導致您根據概括......以及當前關於什么是好的或壞的“實踐”的意見（甚至時尚）來拒絕有效的選擇。

---

由於您想要其他人的意見（“最佳實踐”只是意見！），我認為所有替代方案都是有效的。 但我的投票是將該方法保留為public 。 這是最少的工作，API 中未使用的方法幾乎沒有危害。 正如您所說，該方法將來會被使用是有合理預期的。

你不需要同意你的代碼審查者。 （但這不值得樹敵……）

---

參考：

• James Bach沒有最佳實踐
• 沒有“最佳實踐”這樣的東西：上下文很重要。 通過泰德紐華德。

Answer 2

想要測試私有方法是有意義的。 執行此操作的行業標准方法具有相當多的優勢，如下所示：

• 確保測試代碼與其嘗試測試的代碼位於同一個包中。 這並不意味着相同的目錄； 例如，有src/main/java/pkg/MyClass.java和src/test/java/pkg/MyClassTest.java 。
• 將您的私有方法包設為私有。 如果您想要一些記錄，請使用@VisibleForTesting （來自guava ）注釋它們。

與此不同的是，公共方法的入口空間（從某種意義上說是公共的：這是我的 API 的一部分，定義了外部代碼調用我的代碼的訪問點）通常是一些入口點列表......如果你有的話。 更多的時候根本沒有這樣的定義。 可以說所有公共類型中的所有公共方法都隱含地形成了列表（即關鍵字public暗示它供外部代碼使用），然后通過重言式規定任何公共方法都具有正確的簽名。 不是一個非常有用的定義。 在實踐中，關鍵字public並不一定意味着“這是 API 可訪問的”。 各種模塊系統（例如 jigsaw 或 OSGi）對此都有解決方案，通常是讓您將某些包聲明為實際公開的。

使用此類工具，“搖樹”您的公共方法以指出它們不再需要公開是有意義的。 沒有他們……你真的無法做到這一點。 有這樣一個概念：“我的代碼庫中從未調用過此方法，但它可供外部調用者使用； 我在這里沒有可用的調用者，關鍵是它已發布，並且可能還有尚未開始編寫的項目打算稱之為'。

假設您確實有搖樹的概念，您仍然可以將它們留在“好吧，也許不是今天，但也許明天”的角度。 如果適用，請將其保留。如果您無法想象任何外部代碼需要訪問它的用例，只需將其刪除。 如果它真的需要恢復，嘿，版本控制中總是有歷史記錄。

Answer 3

如果該方法是public static那么您可以保持原樣，因為它是公共的沒有影響。 它是一種無效果的方法，它被暴露永遠不會造成任何傷害。

如果它是對象級公共方法，則 -

1）如果它像一個API，就保留它。 它具有明確定義的輸入、輸出並提供明確定義的功能並具有與之相關的測試。 公開並沒有什么壞處。

2) 如果它有副作用，請立即將其設為私有。 如果它導致其他方法的行為不同，因為它改變了對象的狀態，那么公開是有害的。