什麼是物件導向程式設計？
物件導向程式設計 (OOP) 是一種程式設計範例。 其基礎概念為將相關的資料和函式「分組」成資訊「島」。 這些小島稱為「物件」。
無論使用哪一種範例，程式都會使用相同步驟以解決問題：
- 資料輸入：資料是從某處讀取，可能是檔案系統或資料庫之類的資料儲存體。
- 處理資料：資料經過解譯，可能還會被加以改變，以供顯示之用。
- 資料輸出：資料經呈現後，便可供真人使用者或系統讀取及互動。
OOP 與程序式程式設計的比較
讓我們透過比較 OOP 和其他範例 (程序式程式設計) 以嘗試定義 OOP。 程序式程式設計會透過呼叫程序解決指定的問題，呼叫程序也稱為函式或方法。 函式和變數的建構是為了解決上述各步驟所描述各種階段問題。
OOP 範例在這方面並無不同。 OOP 看待世界的方式讓其脫穎而出。 相較於程序式程式設計，OOP 會退一步，並擁有較好的全局觀。 OOP 不是只處理資料並將資料帶入下一個階段，而是嘗試了解操作資料的這個世界。 OOP 之所以能夠這麼做，是因為其能「模型化」所看到的內容。
OOP 模型化：識別概念
在模型化階段，您要查看定義域的描述，並嘗試分析有關發生情況的文字。 第一個步驟是找出執行者。 其之所以稱為執行者，是因為其有「動作」並執行動作。 例如，印表機 (執行者) 會列印 (動作)。
找出執行者後，您要查看它們在做「什麼」，亦即其行為。 然後，您要查看執行者的描述，以及執行該動作所需的任何資料。 執行者會成為物件，而特性會編碼為物件上的資料，行為則是同時將新增至物件的函式。
其概念為可透過呼叫物件本身其函式來改變物件上的資料。 另外一種概念，就是物件彼此「互動」以獲得實際結果。
OOP 的優點
那為何要使用 OOP 呢？ 為何不使用其他範例呢？ 說得更明白一點，OOP 不比其他任何範例更好或更糟。 每種方法都有利有弊。 OOP 有一些不錯的優點，例如:
- 資料封裝：資料封裝就是向系統的其他部分隱藏資料，只允許某些部分存取。 原因是資料保存「狀態」，而該狀態可由一或多個變數組成。 如果需要同時變更這些變數，您必須保護變數，且只允許透過公開方法存取，讓變更成為可預測。 OOP 具有存取層級之類的機制，讓物件的資料只能由物件本身存取或可公開取得。
- 簡潔：建置大型系統是很複雜的工作，有許多問題需要解決。 能夠將複雜性拆分成較小的問題 (物件)，表示您可「簡化」整體工作。
- 容易修改：當您倚賴物件，並利用它們建立系統模型時，會更容易追蹤到系統需要修改的部分。 例如，您可能需要更正 Bug 或新增功能。
- 可維護性：維護程式碼通常很困難，且會隨著時間變得愈來愈困難。 需要嚴守良好的命名形式和明確一致的架構，以及其他要求。 使用物件可讓您更容易找出程式碼需要維護的特定區域。
- 再使用性：您可以在系統多個部分多次使用同一個物件定義，或許您也可以在其他系統中使用。 重複使用程式碼可節省時間和金錢，因為您需要撰寫的程式碼較少，卻可以更快達到目標。
建立 OOP 系統模型
軟體通常是為了解決需求，讓工作可以更快速、更有效率且更不容易發生錯誤而撰寫。 遇到需要加速進度的情況時，人類敵不過軟體。 使用 OOP 就像是建立練習的模型，因為要撰寫程式碼以執行其邏輯。 模型化就是學習如何識別執行者、所需的資料，以及發生的互動類型。 您只要閱讀對系統的描述即可建立系統的模型。
發票管理系統案例研究
讓我們來看看許多公司的燙手山芋：「發票管理」的手動流程。 許多公司都會收到發票，且需要準時支付。 延遲付款會產生延遲費用，造成金錢的浪費。 但是發票必須先行「處理」才能支付。 發票通常會先過好幾手，才會在某處登錄並予以支付。
此程序通常會從最初的排序階段開始，發票會在此傳送至適當的部門。 接下來，檢查發票的正確性，然後由具有適當授權層級的人員核准。 最後，支付發票。 若為小型企業，可能是企業主自己完成所有步驟。 若為大型公司，則可能涉及許多人和許多程序，使得發票管理成為複雜的活動。
此描述和 OOP 有何關係？ 如果您採用前述的工作流程 (這通常為手動流程)，並將其轉換成已編寫的軟體，您的第一件要務就是嘗試建立系統模型。 在發票管理的內容中，您可藉由閱讀對問題定義域的描述來開始了解執行者 (物件)、行為和資料。
如果將所述的定義域視為具有階段、輸入、處理和輸出，您即可開始填寫如下表中的內容：
| 階段 | 問題為何 |
|---|---|
| 輸入 | 發票 |
| 加工業 | 排序、核准、拒絕 |
| 輸出 | 付款 |
上表描述每個階段中發生的狀況。 您已能夠找到資料、資料在處理期間發生的狀況，以及最終的結果，也就是付款。 此時，仍然可使用您喜歡的任何範例來解決發票管理系統工作流程。 您要如何從這裡進入 OOP？
尋找物件、資料和行為
您可詢問下列問題以尋找系統的不同成品：
- 互動的雙方是誰？
- 一方要對另一方做什麼？
記住這類的問題，您即可使用陳述式。 讓我們醒目提示這些陳述式中的不同成品，以清楚顯示系統的重要部分。
「電子郵件服務」將「發票」「傳送」給系統。
「發票」會按「參考碼」或由「分類人員」手動「排序」，以確保發票到達正確的部門。
「核准者」會根據「數量」的正確性和大小等因素，「核准」或「拒絕」「發票」。
「付款處理器」會依照提供的「付款資訊」來「支付發票」。
您現在可擷取這些句子中的物件、資料和行為，並使用資料表加以組織，如下所示：
| 階段 | 演員 | 行為 | 資料 |
|---|---|---|---|
| 輸入 | 電子郵件服務 | 傳送 | 發票 |
| 輸入 | 系統 | 接收 | 發票 |
| 加工業 | 分類人員或系統 | 排序或路由 | 發票 (參考碼) |
| 加工業 | 核准者 | 核准或拒絕 | 發票 (金額) |
| 輸出 | 付款處理器 | 支付 | 發票 (付款資訊) |
在發票管理系統的初始描述中發生了許多事。 已找到執行者 (物件)。 已識別重要資料，且已使用識別出的物件進行「分組」。 也找到了行為，使執行者 (物件) 彼此間的互動更加清楚。 如此一來，您就能夠找出「誰對誰」執行了何種行為。 此時您已完成初始分析，這是很棒的開始。 但問題還沒解決，您該如何將此分析轉換成程式碼？ 我們要透過本課程模組所得到結果就是此問題的答案。
注意
實際的發票管理系統可能更為複雜，且會依賴更多的資料和邏輯。 能夠以這種方式建立系統模型，表示您使用了結構化的方法思考問題。