Java中封裝的實現，是通過為私有成員提供訪問器方法，即通常所知的getter和setter方法。這樣封裝是否合適仍屬爭議，也超出了本文的討論范圍。但是，當成員變量為集合類型（java.util.Collection，java.util.Map以及它們的子類）時，這樣實現封裝是完全錯誤的。

我經常能見到的代碼像下面這樣：

就我所見，這樣的代碼很普遍，這是由于Hibernate等ORM框架使得這種設計變得流行。很多時候，當我提出我的觀點，得到的建議就是使用一種不可變的設計：

不合適的封裝

然而，在使用集合類型的情形下，由于Java中集合類型自身是可變的，這其實并沒有任何改變。很明顯，無論是通過構造函數傳入一個集合實例的引用，還是返回它的引用，這完全沒有進行封裝。只有當集合實例的引用沒有（在外部）保留，也不會返回（到外部），真正的封裝才有可能實現。

不能使用具體的子類

另外，MyBean類可能需要封裝一種更具體的集合類，比如List或者Set。從下面的代碼片段可以看出，傳入一個Set實例是不可能的。

不能選擇具體的實現

由上一點很自然地想到，使用（外部）提供的引用的話，我們也無法使用（可能為了更高效）自己定義的類，比如Apache Commons的FastArrayList。

實現建議

下面的代碼做到了真正封裝的出發點。

這種方式解決了前面提到的幾個問題：

集合實例的引用沒有從構造函數中傳入，這樣就不可能在實例外部改變實例。

由于完全隔離，可以自由地選擇集合的實現，為修改留下余地。

不能通過getter訪問器方法獲得被封裝的集合實例的引用。

注意：為了可讀性，前面的代碼片段沒有使用泛型。請在實際使用中加上。

以上就是動力節點java培訓機構的小編針對“基礎內容分享：Java封裝練習題”的內容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業老師隨時為你服務。