為方便後面的討論
讓我們先對這一領域的從業人員作一下分類
從根本上說
大致有兩方面的人員涉足面向對象的編程
類創建者
(創建新數據類型的人)以及
客戶程序員
(在自己的應用程序中采用現成數據類型的人)
對客戶程序員來講
最主要的目標就是收集一個充斥著各種類的編程
工具箱
以便快速開發符合自己要求的應用
而對類創建者來說
他們的目標則是從頭構建一個類
只向客戶程序員開放有必要開放的東西(接口)
其他所有細節都隱藏起來
為什麼要這樣做?隱藏之後
客戶程序員就不能接觸和改變那些細節
所以原創者不用擔心自己的作品會受到非法修改
可確保它們不會對其他人造成影響
接口
(Interface)規定了可對一個特定的對象發出哪些請求
然而
必須在某個地方存在著一些代碼
以便滿足這些請求
這些代碼與那些隱藏起來的數據便叫作
隱藏的實現
站在程式化程序編寫(Procedural Programming)的角度
整個問題並不顯得復雜
一種類型含有與每種可能的請求關聯起來的函數
一旦向對象發出一個特定的請求
就會調用那個函數
我們通常將這個過程總結為向對象
發送一條消息
(提出一個請求)
對象的職責就是決定如何對這條消息作出反應(執行相應的代碼)
對於任何關系
重要一點是讓牽連到的所有成員都遵守相同的規則
創建一個庫時
相當於同客戶程序員建立了一種關系
對方也是程序員
但他們的目標是組合出一個特定的應用(程序)
或者用您的庫構建一個更大的庫
若任何人都能使用一個類的所有成員
那麼客戶程序員可對那個類做任何事情
沒有辦法強制他們遵守任何約束
即便非常不願客戶程序員直接操作類內包含的一些成員
但倘若未進行訪問控制
就沒有辦法阻止這一情況的發生——所有東西都會暴露無遺
有兩方面的原因促使我們控制對成員的訪問
第一個原因是防止程序員接觸他們不該接觸的東西——通常是內部數據類型的設計思想
若只是為了解決特定的問題
用戶只需操作接口即可
毋需明白這些信息
我們向用戶提供的實際是一種服務
因為他們很容易就可看出哪些對自己非常重要
以及哪些可忽略不計
進行訪問控制的第二個原因是允許庫設計人員修改內部結構
不用擔心它會對客戶程序員造成什麼影響
例如
我們最開始可能設計了一個形式簡單的類
以便簡化開發
以後又決定進行改寫
使其更快地運行
若接口與實現方法早已隔離開
並分別受到保護
就可放心做到這一點
只要求用戶重新鏈接一下即可
Java采用三個顯式(明確)關鍵字以及一個隱式(暗示)關鍵字來設置類邊界
public
private
protected以及暗示性的friendly
若未明確指定其他關鍵字
則默認為後者
這些關鍵字的使用和含義都是相當直觀的
它們決定了誰能使用後續的定義內容
public
(公共)意味著後續的定義任何人均可使用
而在另一方面
private
(私有)意味著除您自己
類型的創建者以及那個類型的內部函數成員
其他任何人都不能訪問後續的定義信息
private在您與客戶程序員之間豎起了一堵牆
若有人試圖訪問私有成員
就會得到一個編譯期錯誤
friendly
(友好的)涉及
包裝
或
封裝
(Package)的概念——即Java用來構建庫的方法
若某樣東西是
友好的
意味著它只能在這個包裝的范圍內使用(所以這一訪問級別有時也叫作
包裝訪問
)
protected
(受保護的)與
private
相似
只是一個繼承的類可訪問受保護的成員
但不能訪問私有成員
繼承的問題不久就要談到
From:http://tw.wingwit.com/Article/program/Java/Javascript/201311/25441.html