本文部分摘自 On Java 8
面向物件編程
在提及面向物件時，不得不提到另一個概念：抽象，編程的最終目的是為了解決某個問題，問題的復雜度直接取決于抽象的型別和質量，早期的匯編語言通過對底層機器作輕微抽象，到后來的 C 語言又是對匯編語言的抽象，盡管如此，它們的抽象原理依然要求我們著重考慮計算機的底層結構，而非問題本身
面向物件編程（Object-Oriented Programming OOP）是一種編程思維方式和編碼架構，不同于傳統的面向程序編程，面向物件編程把問題空間（實際要解決的問題）中的元素以及它們在解決方案空間中的表示以一種具有普遍性的方式表達出來，這種表示被稱作物件（Object），對于一些在問題空間無法對應的物件，我們還可以添加新的物件型別，以配合解決特定的問題，總而言之，OOP 允許我們根據問題來描述問題，而不是根據解決問題的方案，每個物件都有自己的狀態，并且可以進行特定的操作，換言之，它們都有自己的特征和行為
根據面向物件編程的概念，可以總結出五大基本特征：
- 萬物皆物件
- 程式是一組物件，可以互相傳遞訊息以告知彼此應該做什么
- 每個物件都有自己的存盤空間，以容納其他物件
- 每個物件都有一種型別
- 同一個類的所有物件能接收相同的訊息
對物件更簡潔的描述是：一個物件具有自己的狀態、行為和標識，這意味著物件有自己的內部資料（狀態）、方法（行為），并彼此區分（每個物件在記憶體中都有唯一的地址）
介面
所有物件都是唯一的，但同時也是具有相同的特征和行為的物件所歸屬的類的一部分，這種思想被應用于面向物件編程，并在程式中使用基本關鍵字 class 來表示型別，每個類都有自己的通用特征和行為，創建好一個類后，可生成許多物件，這些物件作為要解決問題中存在的元素進行處理，事實上，當我們在進行面向物件程式設計時，面臨的最大的一項挑戰就是：如何在問題空間與方案空間的元素之間建立理想的一對一映射關系？
如果無法建立有效的映射，物件也就無法做真正有用的作業，必須有一種方法能向物件發出請求，令其解決一些實際的問題，比如完成一次交易、打開一個開關等，每個物件僅能接收特定的請求，我們向物件發出的請求是通過它的介面定義的
比如有一個電燈類 Light，我們可以向 Light 物件發出的請求包括打開 on、關閉 off，因此在 Light 類我們需要定義兩個方法 on() 和 off()，然后創建一個 Light 型別的物件，并呼叫其介面方法
也行你已經發現了，物件通過接受請求并反饋結果，因此我們可以將物件看成是某項服務的提供者，也就是說你的程式將為用戶提供服務，并且它能還能通過呼叫其他物件提供的服務來實作這一點，我們的最終目標是開發或呼叫工具庫中已有的一些物件，提供理想的服務來解決問題
更進一步，我們需要將問題進行分解，將其抽象成一組服務，并有組織地劃分出每一個功能單一、作用明確且緊密的模塊，避免將太多功能塞進一個物件里，這樣的程式設計可以提高代碼的復用性，同時也方便別人閱讀和理解我們的代碼
封裝
我們把編程的側重領域劃分為研發和應用兩塊，應用程式員呼叫研發程式員構建的基礎工具類做快速開發，研發程式員開發一個工具類，該工具類僅向應用程式員公開必要的內容，并隱藏內部實作的細節，這樣可以有效避免工具類被錯誤使用和更改，顯然，我們需要某些方法來保證工具類的正確使用，只有設定訪問控制，才能從根本上解決這個問題
因此，使用訪問控制的原因有以下兩點：
- 讓應用程式員不要觸碰他們不應該觸碰的部分
- 類別庫的創建者可以在不影響他人使用的情況下完善和更新工具庫
Java 提供了三個顯式關鍵字來設定類的訪問權限，分別是 public（公開）、private（私有）和 protected（受保護），這些訪問修飾符決定了誰能使用它們修飾的方法、變數或類
-
public
表示任何人都可以訪問和使用該元素
-
private
除了類本身和類內部的方法，外界無法直接訪問該元素
-
protected
被 protected 修飾的成員對于本包和其子類可見，這句話有點太籠統了，更具體的概括應該是：
- 基類的 protected 是包內可見的
- 若子類與基類不在同一包中，那么子類實體可以訪問從基類繼承而來的 protected 方法，而不能訪問基類實體的 protected 方法
-
default
如果不使用前面三者，默認就是 default 權限，該權限下的資源可以被同一包中其他類的成員訪問
復用
代碼和設計方案的復用性是面向物件的優點之一，我們可以通過重復使用某個類的物件來實作復用性，例如，將一個類的物件的作為另一個類的成員變數使用，因此，新構成的類可以是由任意數量和任意型別的其他物件構成，這里涉及到了組合和聚合兩個概念：
- 組合（Composition）經常用來表示擁有關系（has-a relationship）例如，汽車擁有引擎，組合關系中，整件擁有部件的生命周期，所以整件洗掉時，部件一定會跟著洗掉
- 聚合（Aggregation）表示動態的組合，聚合關系中，整件不會擁有部件的生命周期，所以整件洗掉時，部件不會洗掉
使用組合可以為我們的程式帶來極大的靈活性，通常新建的類中，成員物件會使用 private 訪問權限，這樣應用程式員無法對其直接訪問，我們就可以在不影響客戶代碼的前提下，從容地修改那些成員，我們也可以在運行時改變成員物件，從而動態地改變程式的行為，下面提到的繼承并不具備這種靈活性，因為編譯器對通過繼承創建的類進行了限制
繼承
物件的概念為編程帶來便利，它允許我們將各式各樣的資料和功能封裝到一起，這樣可以恰當表達問題空間的概念，而不用受制于必須使用底層機器語言
通過 class 關鍵字，可以形成編程語言中的基本單元，遺憾的是，這樣做還是有很多問題：在創建一個類之后，即使另一個新類與其具有相似的功能，你還是不得不重新創建一個新類，如果我們能利用現有的資料型別，對其進行克隆，再根據情況進行添加和修改，那就方便許多了，繼承正是為此而設計，但繼承并不等價于克隆，在繼承程序中，如原始類（基類、父類）發生了變化，修改過的克隆類（子類、派生類）也會反映出這種變化
基類一般會有多個派生類，并包含派生自它的型別之間共享的所有特征和行為，后者可能比前者包含更多的特征，并可以處理更多訊息（或者以不同的方式處理它們）
使用繼承，你將構建一個型別層次結構，來表示你試圖解決的某種型別的問題，常見的例子是形狀，每個形狀都有大小、顏色、位置等等，每個形狀可以繪制、擦除、移動等，還可以派生出具體型別的形狀，如圓形、正方形、三角形等等，派生出的每個形狀都可以具有附加的特征和行為，例如，某些形狀可以翻轉，計算形狀面積的公式互不相同等等
型別層次結構體現了形狀之間的相似性和差異性，你不需要在問題描述和解決方案描述之間建立許多中間模型，從現有型別繼承并創建新型別，新型別不僅包含現有型別的所有成員（盡管私有成員被隱藏起來并不可訪問），更重要的是它復制了基類的介面，也就是說，基類物件能接收的訊息派生類物件也能接收，如果基類不能滿足你的需求，你可以在派生類添加更多的方法，甚至改變現有基類方法的行為（覆寫），只需在派生類重新定義這個方法即可
多型
在處理類的層次結構時，通常把一個物件看成是它所屬的基類，而不是把它當成具體類，通過這種方式，我們可以撰寫出不局限于特定型別的代碼，例如上述形狀的例子，方法操縱的是通用的形狀，而不關心具體是圓還是三角形什么的，所有形狀都可以被繪制、擦除和移動，因此方法向其中任何代表形狀的物件發送訊息都不必擔心物件如何處理資訊
這種能力改善了我們的設計，減少了軟體的維護代價，如果我們把派生物件型別統一看成是它本身的基類，編譯器在編譯時就無法準確地獲知具體是哪個形狀被繪制，那一種車正在行駛，這正是關鍵所在：當程式接受這種訊息時，程式員并不關心哪段代碼會被執行，繪圖方法可以平等地應用到每種可能的形狀上，形狀會依據自身的具體型別執行恰當的代碼
因此，我們就能添加一個新的不同執行方式的子類而不需要更改呼叫它的方法，更利于程式擴展，那么編譯器如何確定該執行哪部分的代碼呢？一般來說，編譯器不能進行函式呼叫，對于非 OOP 編譯器產生的函式呼叫會引起所謂的早期系結，這意味著編譯器生成對特定函式名的呼叫，該呼叫會被決議為將執行的代碼的絕對地址，而面向物件語言使用了一種后期系結的概念，當向物件發送資訊時，被呼叫的代碼直到運行時才確定，編譯器要做的只是確保方法存在，并對引數和回傳值執行型別檢查，但并不知道要執行的確切代碼
為了執行后期系結，Java 使用一個特殊的代碼位來代替絕對呼叫，這段代碼使用物件中存盤的資訊來計算方法主體的地址，因此，每個物件的行為根據特定代碼位的內容而不同，當你向物件發送訊息時，物件知道該如何處理這條訊息，在某些語言如 C++ 必須顯式地授予方法后期系結屬性的靈活性，而在 Java 中，動態系結是默認行為，不需要額外的關鍵字來實作多型性
發送訊息給物件時，如果程式不知道接收的具體型別是什么，但最終執行是正確的，這就是物件的多型性，面向物件的程式設計語言是通過動態系結的方式來實作物件的多型性的，編譯器和運行時系統會負責控制所有的細節，我們只需要知道要做什么，以及如何利用多型性更好地設計程式
物件創建與生命周期
在使用物件時要注意的一個關鍵問題就是物件的創建和銷毀方式，每個物件的生存都需要資源，尤其是記憶體，當物件不再被使用時，我們應該及時釋放資源，清理記憶體
然而，實際的情形往往要復雜許多，我們怎么知道何時清理這些物件呢？也許一個物件在某一系統中處理完成，但在其他系統可能還沒處理完成，另外，物件的資料在哪？如何控制它的生命周期？在 C++ 設計中采用的觀點是效率第一，它將這些問題的選擇權交給了程式員，程式員在撰寫程式時，通過將物件放在堆疊或靜態存盤區域中來確定記憶體占用和生存空間，相對的，我們也犧牲了程式的靈活性
Java 使用動態記憶體分配，在堆記憶體中動態地創建物件，在這種方式下，直到程式運行我們才能知道創建的物件數量、生存型別和時間，在堆記憶體上開辟空間所需的時間可能比堆疊記憶體要長（但并不一定），但動態分配論認為：物件通常是復雜的，相比于物件創建的整體開銷，尋找和釋放記憶體空間的開銷微不足道，對于物件的生命周期問題，在 C++ 中你必須以編程方式確定何時銷毀物件，而 Java 的垃圾收集機制能自動發現不再被使用的物件并釋放相應的記憶體空間，使得 Java 的編碼程序比用 C++ 要簡單許多
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/239881.html
標籤：Java