Java 訪問權限修飾符深度解析：為什麼類/接口不能用 private/protected、接口方法只能 public

類的訪問修飾符限制

private：毫無意義

頂級類若為 private，任何其他類均不可見，無法實例化、繼承、引用，喪失存在意義。（內部類除外）

protected：邏輯悖論

假設類 A 為 protected，類 B 在不同包：

• B 訪問 A 的前提：B 是 A 的子類
• B 成為 A 子類的前提：B 能訪問 A

形成循環依賴，無法打破。因此頂級類只能是 public 或 default（包私有）。

接口方法的修飾符限制

接口定義契約，供異包類實現。分析各修飾符：

private：不可見不可實現

方法 private → 任何實現類不可見 → 無法實現 → 違背接口目的。

protected：破壞面向接口編程

假設 public interface I 有 protected void m()：

• 異包 public class C implements I 實現 m() 仍為 protected
• 同包類 D 調用：C c = new C(); c.m(); ✅
• 但接口引用調用失效：I i = new C(); i.m(); ❌（protected 不對異包接口引用可見）

失去「統一接口、面向抽象」核心價值。

default（包私有）：異包無法實現

public interface I 有 default void m() → 異包類實現時方法不可見 → 編譯錯誤。

default 接口中的 default 方法理論可行但被禁

default interface I { default void m(); } 同包內可實現，但為簡化規則、避免「public 接口不能用、default 接口能用」的認知負擔，統一禁止。

結論：接口方法隱式 public

• 接口方法只能是 public
• 編譯器自動補全：省略修飾符等同 public abstract
• Java 8+ 默認方法 default void m()、靜態方法 static void m() 也必須 public

修飾符對比總結表

設計原則啟示

• 封裝性：默認用 private，按需放寬
• 接口隔離：接口只暴露 public 契約
• 繼承謹慎：protected 僅用於「設計為被繼承」的類成員
• 包邊界：default 限制在包內協作，模塊化利器

理解修飾符背後的「可見性邏輯與設計意圖」，比死記表格更能指導實際架構決策。