## [本章小結](https://lingcoder.gitee.io/onjava8/#/book/07-Implementation-Hiding?id=%e6%9c%ac%e7%ab%a0%e5%b0%8f%e7%bb%93) 無論在什么樣的關系中，劃定一些供各成員共同遵守的界限是很重要的。當你創建了一個類庫，也就與該類庫的使用者產生了聯系，他們是類庫的客戶端程序員，需要使用你的類庫創建應用或更大的類庫。 沒有規則，客戶端程序員就可以對類的所有成員為所欲為，即使你希望他們不要操作部分成員。這種情況下，所有事物都是公開的。 本章討論了類庫是如何通過類構建的：首先，介紹了將一組類打包到類庫的方式，其次介紹了類如何控制對其成員的訪問。 據估計，用 C 語言開發項目，當代碼量達到 5 萬行和 10 萬行時就會出現問題，因為 C 語言只有單一的命名空間，名稱開始沖突造成額外的管理開銷。在 Java 中，關鍵字**package**，包命名模式和關鍵字**import**給了你對于名稱的完全控制權，因此可以輕易地避免名稱沖突的問題。 控制成員訪問權限有兩個原因。第一個原因是使用戶不要接觸他們不該接觸的部分，這部分對于類內部來說是必要的，但是不屬于客戶端程序員所需接口的一部分。因此將方法和屬性聲明為**private**對于客戶端程序員來說是一種服務，可以讓他們清楚地看到什么是重要的，什么可以忽略。這可以簡化他們對類的理解。 第二個也是最重要的原因是為了讓類庫設計者更改類內部的工作方式，而不用擔心會影響到客戶端程序員。比如最初以某種方式創建一個類，隨后發現如果更改代碼結構可以極大地提高運行速度。如果接口與實現被明確地隔離和保護，你可以實現這一目的，而不必強制客戶端程序員重新編寫代碼。訪問權限控制確保客戶端程序員不會依賴某個類的底層實現的任何部分。 當你具備更改底層實現的能力時，不但可以自由地改善設計，還可能會隨意地犯錯。無論如何細心地計劃和設計，都有可能犯錯。當了解到犯錯是相對安全的時候，你可以更加放心地實驗，更快地學會，更快地完成項目。 類的**public**接口是用戶真正看到的，所以在分析和設計階段決定這部分接口是最重要的部分。盡管如此，你仍然有改變的空間。如果最初沒有創建出正確的接口，可以添加更多的方法，只要你不刪除那些客戶端程序員已經在他們的代碼中使用的東西。 注意到訪問權限控制關注的是類庫創建者和外部使用者之間的關系，這是一種交流方式。很多情況下，事實并非如此。例如，你自己編寫了所有的代碼，或者在一個小組中工作，所有的東西都放在同一個包下。這些情況下，交流方式則是另外一種，此時嚴格地遵循訪問權限規則也許不是最佳選擇，默認（包）訪問權限也許就足夠好了。