# [第七章 封裝](https://lingcoder.gitee.io/onjava8/#/book/07-Implementation-Hiding?id=%e7%ac%ac%e4%b8%83%e7%ab%a0-%e5%b0%81%e8%a3%85) > *訪問控制（Access control）*（或者*隱藏實現（implementation hiding）*）與“最初的實現不恰當”有關。 所有優秀的作者——包括那些編寫軟件的人——都知道一件好的作品都是經過反復打磨才變得優秀的。如果你把一段代碼置于某個位置一段時間，過一會重新來看，你可能發現更好的實現方式。這是*重構*（refactoring）的原動力之一，重構就是重寫可工作的代碼，使之更加可讀，易懂，因而更易維護。 但是，在修改和完善代碼的愿望下，也存在巨大的壓力。通常，一些用戶（*客戶端程序員（client programmers）*）希望你的代碼在某些方面保持不變。所以你想修改代碼，但他們希望代碼保持不變。由此引出了面向對象設計中的一個基本問題：“如何區分變動的事物和不變的事物”。 這個問題對于類庫（library）而言尤其重要。類庫的使用者必須依賴他們所使用的那部分類庫，并且知道如果使用了類庫的新版本，不需要改寫代碼。另一方面，類庫的開發者必須有修改和改進類庫的自由，并保證客戶代碼不會受這些改動影響。 這可以通過約定解決。例如，類庫開發者必須同意在修改類庫中的一個類時，不會移除已有的方法，因為那樣將會破壞客戶端程序員的代碼。與之相反的情況更加復雜。在有成員屬性的情況下，類庫開發者如何知道哪些屬性被客戶端程序員使用？這同樣會發生在那些只為實現類庫類而創建的方法上，它們也不是設計成可供客戶端程序員調用的。如果類庫開發者想刪除舊的實現，添加新的實現，結果會怎樣呢？任何這些成員的改動都可能破環客戶端程序員的代碼。因此類庫開發者會被束縛，不能修改任何事物。 為了解決這一問題，Java 提供了*訪問修飾符*（access specifier）供類庫開發者指明哪些對于客戶端程序員是可用的，哪些是不可用的。訪問控制權限的等級，從“最大權限”到“最小權限”依次是：**public**，**protected**，*包訪問權限（package access）*（沒有關鍵字）和**private**。根據上一段的內容，你可能會想，作為一名類庫設計者，你會盡可能將一切都設為**private**，僅向客戶端程序員暴露你愿意他們使用的方法。這就是你通常所做的，盡管這與那些使用其他語言（尤其是 C）編程以及習慣了不受限制地訪問任何東西的人們的直覺相違背。 然而，類庫組件的概念和對類庫組件訪問的控制仍然不完善。其中仍然存在問題就是如何將類庫組件捆綁到一個內聚的類庫單元中。Java 中通過**package**關鍵字加以控制，類在相同包下還是在不同包下，會影響訪問修飾符。所以在這章開始，你將會學習如何將類庫組件置于同一個包下，之后你就能明白訪問修飾符的全部含義。