“進行面向對象的設計時，一項基本的考慮是：如何將發生變化的東西與保持不變的東西分隔開。”
這一點對於庫來說是特別重要的。那個庫的用戶（客戶程序員）必須能依賴自己使用的那一部分，並知道一旦新版本的庫出台，自己不需要改寫代碼。而與此相反，庫的創建者必須能自由地進行修改與改進，同時保證客戶程序員代碼不會受到那些變動的影響。
為達到這個目的，需遵守一定的約定或規則。例如，庫程序員在修改庫內的一個類時，必須保證不刪除已有的方法，因為那樣做會造成客戶程序員代碼出現斷點。然而，相反的情況卻是令人痛苦的。對於一個數據成員，庫的創建者怎樣才能知道哪些數據成員已受到客戶程序員的訪問呢？若方法屬於某個類唯一的一部分，而且並不一定由客戶程序員直接使用，那麼這種痛苦的情況同樣是真實的。如果庫的創建者想刪除一種舊有的實施方案，並置入新代碼，此時又該怎麼辦呢？對那些成員進行的任何改動都可能中斷客戶程序員的代碼。所以庫創建者處在一個尴尬的境地，似乎根本動彈不得。
為解決這個問題，Java推出了“訪問指示符”的概念，允許庫創建者聲明哪些東西是客戶程序員可以使用的，哪些是不可使用的。這種訪問控制的級別在“最大訪問”和“最小訪問”的范圍之間，分別包括：public，“友好的”（無關鍵字），protected以及private。根據前一段的描述，大家或許已總結出作為一名庫設計者，應將所有東西都盡可能保持為“private”（私有），並只展示出那些想讓客戶程序員使用的方法。這種思路是完全正確的，盡管它有點兒違背那些用其他語言（特別是C）編程的人的直覺，那些人習慣於在沒有任何限制的情況下訪問所有東西。到這一章結束時，大家應該可以深刻體會到Java訪問控制的價值。
然而，組件庫以及控制誰能訪問那個庫的組件的概念現在仍不是完整的。仍存在這樣一個問題：如何將組件綁定到單獨一個統一的庫單元裡。這是通過Java的package（打包）關鍵字來實現的，而且訪問指示符要受到類在相同的包還是在不同的包裡的影響。所以在本章的開頭，大家首先要學習庫組件如何置入包裡。這樣才能理解訪問指示符的完整含義。
