物件導向程式設計（文章翻譯）

譯者：不幸的是，儘管我讀了很多英文書，但我在英文翻譯方面沒有任何豐富的經驗。但事實證明，閱讀和翻譯是兩件不同的事。另外，不幸的是，我沒有豐富的程式設計經驗（我最近剛用 Spring MVC 和 Hibernate 製作了一個簡單的 Web 應用程式）。因此，翻譯的結果比預期的要糟糕得多。我冒昧地稍微修正了文章中給出的程式碼範例，因為它們不符合 Java 中的命名約定。也許不值得翻譯某些模式的名稱（這樣的翻譯並不能提供太多理解），但我認為這是兩害相權取其輕的做法。值得單獨提及的是「high cohesion」作為「high cohesion」的翻譯。我同意，這不是最好的翻譯。但「強連結」是「高耦合」（另一個重要概念），「一致性」在這裡不太適用。我樂於接受批評，並非常樂意接受任何形式的對本文的評論。 物件導向程式設計是一種程式設計風格，其中程式由與現實世界物件相對應的元件組成。任何真實物件都具有一些屬性（可能會或可能不會隨著時間而改變）和行為（可能會或可能不會）取決於其他）。條件）。例如，鉛筆是現實世界中的對象，具有以下屬性：

• 它是紅色的（不會隨著時間的推移而改變）。
• 現在長 10 公分（如果鉛筆削尖，長度可能會改變）。

它具有以下行為：

• 如果使用得當，它會留下痕跡。
• 跡線可能會因壓力而異（取決於外部因素）。
• 如果削尖，其長度會縮短（永久行為）。

如本例所示，現實世界中的物件可以具有許多屬性，但在編寫程式時我們只考慮必要的屬性。物件導向程式設計有其優點。例如，它可以更輕鬆地以預期的方式在現實世界的物件和程式之間建立連接。隨著應用程式的成長以及許多物件之間的交互，這確實很有幫助。這有助於在客觀世界中分配責任，使您能夠專注於透過應用程式進行思考。與OOP （物件導向程式設計）相關的另一個重要特徵是物件的分類。由於世界（真實/虛擬）充滿了物體，因此很難單獨控制它們。我們需要一種對這些物件進行分類的方法，以幫助我們將不同的物件及其屬性（例如黑色鉛筆）關聯起來。如果在前面的範例中使用，它將無法區分（相同？），但它是一個不同的物件。但由於它們都是鉛筆，所以它們屬於同一類「鉛筆」。而鋼筆與鉛筆非常相似，但屬於不同的類別。然而，鋼筆和鉛筆都是「書寫工具」。 物件導向程式設計有以下原則：

抽象

抽像被定義為與思想而非事件互動的質量，或者換句話說，不受表徵品質的影響。這使得程式設計師可以專注於程式設計什麼而不是如何程式設計。抽象可以被認為是我們提供功能的契約。使用此概念時，實作細節可能會被隱藏。例如，如果我們需要一個可以寫的類，那麼我們必須確保它有一個「write」方法， abstract class writer { write (); } 我們做了什麼？我們設計了一個抽象的高級類，換句話說，它知道我們需要什麼功能，但如何實現它超出了該類別的範圍。這提供了許多好處：

• 我們向外部實體披露最少的必要信息，這使我們能夠專注於透過計劃進行思考（這可以實現集中思考），避免混亂並避免做出無意的承諾。
• 我們為未來的改進留出了空間，如果透露實施細節，這些改進將是不可能的。

遺產

「繼承」在普通英語中的意思是「獲得並傳承」。這個詞在我們的文化中已經存在很久了。祖先們透過辛勤工作獲得了土地並將其傳給子孫，甚至大自然也青睞繼承。所有身體特徵，例如身高、皮膚/眼睛/頭髮顏色等。取決於我們從父母那裡繼承的基因。繼承可以防止重新發明輪子並加快進步。在 OOP 中也是如此。我們建立一個具有一些基本屬性/行為的父類別。從該父級繼承的所有類別都將包含與其父級相同的屬性/行為。但是，繼承的類別可能會獲得更多屬性/行為或更改行為的實作。 class WritingInstrument { colour; write() { } } class Pen (child of parent) { inkcolour; } 在上面的範例中，父類別（WritingInstrument）具有「顏色」屬性和「寫入」行為。當子類別（句柄）被聲明時，「顏色」屬性和「寫入」行為不需要再次聲明。由於繼承，它們出現在“handle”類別中。但是，後代類別可以聲明自己的附加屬性/行為。我們如何在實踐中使用它？我們開發者很懶。我們不想一遍又一遍地印製一些東西。由於以下考慮，不鼓勵存在相同程式碼的多個副本：

• 程式碼副本越少，就越容易維護。
• 如果程式碼的副本不多，那麼一處的變更就會變得隨處可見。
• 程式碼越少，錯誤就越少。
• 如果一種程式碼在很多地方使用，那麼就實現了泛化。
• 我們專注於編寫程式碼。
• 我們專注於測驗。

Java 中的繼承是透過關鍵字「extends」和「implements」來實現的。 class WritingInstrument { } class Pen extends WritingInstrument { }

多態性

「多態性」一詞來自兩個字： 「Poly」，即 “許多”/“多個” “變形”，即 「形式」 從字面上看，「多態性」一詞是指物件根據條件以不同方式表現的能力。在程式設計中，多態性可以在幾個地方實現：

• 課程
• 方法
• 營運商

上述所有內容的行為可能會有所不同，具體取決於使用它們的條件（也許是上下文）。這很有用，因為客戶端（使用庫的程式設計師）不需要了解很多細節，並且透過從上下文中選擇必要的資訊來實現所需的功能。 Class WritingObject { wrire() { // пишем, используя стандартные (по дефолту) цвета } } class Pencil extends WritingObject { write() { // пишем, используя серый цвет, написанный текст можно стереть } } class Pen extends WritingObject { write() { // пишем, используя голубой цвет, написанный текст нельзя стереть } } class Main { main() { WritingObject wr = new WritingObject(); wr.write(); // первый вызов WritingObject wr = new Pen(); wr.write(); // второй вызов WritingObject wr2 = new Pencil(); wr2.write(); // третий вызов } } 上面的範例在writingObject中有一個預設實現，它由後代類別pen和pen擴展/覆蓋。在 Main 類別中 write() 方法被呼叫了 3 次。每次呼叫不同的實作時，都會根據呼叫該方法的物件來呼叫。在本例中，write() 方法具有多種類型的行為，因為它是多態的。

封裝

封裝被定義為將相關資料/功能收集在一個單元中。這有助於促進數據存取/修改。例如，如果我們需要列印給定使用者擁有的所有屬性，我們有以下選擇： 我們 printUserProperties(userName, userId, firstname, lastname, email, phone, … … ….) 建立了一種方法，該方法會取得所有屬性並依序列印它們。隨著清單中元素數量的增加，將不再可能識別正確的字段，並且添加/刪除一個字段將更改方法簽名。因此，我們需要替換該方法的所有用戶，即使他們不需要最近新增的欄位。為了使程式碼更具可讀性並方便以後的修改，我們將屬性封裝在類別中，並將其變成一個集體物件。 class User { userName userId firstname lastname email phone .. .. .. } printUserProperties(user) {} 物件是變數和關聯方法的軟體包。您可以使用程式物件來表示現實世界的物件。您可以想像動畫程式中的真實狗，或是將真實的自行車想像為健身車內的軟體物件。在 OOP 中，類別是一個可擴展模板（程式碼模板），用於建立物件、為它們提供初始狀態（變數）和實作行為（函數、方法）。SOLID 是 Michael Feather 為 2000 年代初 Robert C. Martin 提出的「前五項原則」所創造的縮寫。這些原則的目標是，當一起實施時，增加程式設計師創建易於維護和擴展的系統的可能性。SOLID 原則是程式開發中的指南，需要透過重構來刪除「腐爛」的程式碼，從而使程式碼變得易於閱讀和擴展。這是敏捷和自適應程式設計策略的一部分。

單一責任原則

在 OOP 中，單一職責原則規定每個類別應該負責程式提供的一部分功能，並且該職責應該完全由該類別封裝。它的所有功能都應該與這個職責密切相關。

開閉原理

在 OOP 中，開放/封閉原則指出“軟體實體（類別、模組、方法等）應該對擴展開放，但對更改封閉。” 換句話說，實體必須允許在不更改原始程式碼的情況下擴展其行為。

里氏替換原則

可替代性是 OOP 中的一個原則。它指出，如果電腦程式中的 S 是 T 的子類型，那麼 T 類型的物件必須可以被 S 類型的物件取代（即 S 類型的物件可以被 T 類型的物件取代）而不改變任何所需的屬性程序（準確性、任務完成情況等）。

介面隔離原則

介面分離的原則規定，客戶端程式設計師不應被迫依賴其不使用的方法。根據這個原則，有必要將大的介面分成更小、更具體的接口，以便客戶端程式設計師只知道他感興趣的方法。介面解耦原則的目的是讓系統保持解耦，這樣會更容易重構、更改和重新部署。

依賴倒置原則

在OOP中，依賴倒置原則是指程式模組斷開的一種特定形式。遵循這一原則，將構成應用架構（策略設定）的高層模組與依賴的低層模組建立的標準​​依賴關係顛倒（反轉），使得修改後的高層模組變得獨立於應用程式的實現細節。低階模組。該原則規定：

• 高層模組不應該依賴低層模組。兩種類型的模組都必須依賴抽象。
• 抽像不應依賴實作細節。細節必須依賴抽象。

這個原則顛倒了人們思考物件導向設計的方式，認為高層和低層物件應該依賴相同的抽象。

掌握原則

通用職責分配軟體模式 (GRASP) 提供了在物件導向設計中將職責指派給類別和物件的指南。

控制器

控制器模式將與系統事件​​互動的責任分配給代表整個系統或用例場景的非 GUI 類別。控制器：

• 這是一個不直接與使用者互動的對象，負責接收和回應系統事件。
• 必須用於處理一個（或多個相關）用例的所有系統事件。
• 它是 GUI 背後控制系統操作的第一個物件。
• 他不必自己做這項工作；他的任務是控制事件的流程。

創作者

創建者類別的任務是建立並啟動物件以供後續使用。它知道初始化參數，以及將創建什麼物件。有時創建者類別會主動建立物件並將其放入快取中，並在需要時提供一個實例。

高內聚力

高內聚是一種評估模式，其目的是將物件保持在一種狀態，即它們旨在執行一項明確的任務，易於控制和理解。高耦合通常用來支援低耦合。高一致性意味著給定元素的職責被明確定義（強相關且高度集中）。將程式劃分為類別和子系統是增加系統屬性內聚性的操作範例。另一方面，松耦合是指一個元素有太多不相關任務的情況。鬆散耦合的元素往往難以理解、可重複使用、難以維護且難以更改。

間接

Roundabout 模式透過將兩個元素之間的互動責任分配給中間物件來保持兩個元素之間的鬆散耦合（和可重複使用性）。一個範例是在模型-視圖-控制器 (MVC) 模式中引入控制器來協調資料（模型）及其顯示（視圖）。

資訊專家

資訊專家（也稱為專家或專家原則）是用來確定將責任委託給誰的原則。職責包括方法、計算欄位等。當使用此原則分配責任時，主要方法是以下操作序列：分析責任，識別履行責任所需的信息，最後確定該資訊的位置。使用資訊專家原則會將責任分配給擁有最多執行資訊的類別。

低耦合

松耦合是一種評估模式，指定如何分配職責：類別之間的鬆散耦合，更改一個對另一個的影響應該最小，並最大限度地提高可重用性。

多態性

根據多態性，基於類型的行為變化被分配給發生這種變化的類型。這是透過使用多態操作來實現的。

受保護的變體

受保護的變更模式透過將不穩定的焦點包裝在介面中並使用多態性來建立該介面的不同實現，從而保護元素免受其他元素（物件、系統、子系統）的變更。

純製造

純構造涉及一個不代表問題域中的概念的類，並且專門設計用於實現鬆散耦合、高耦合，從而實現最大的重用潛力（資訊專家模式提供的解決方案無法實現這一點）。這樣的類別在領域驅動設計中通常稱為「服務」。

批評

Potok 等人的研究顯示 OOP 和製程方法之間沒有顯著差異。

由於缺乏嚴格且廣泛接受的 OOP 定義，將 OOP 與其他技術（尤其是關係技術）進行批判性比較是很困難的（Christopher J. Date）

與其他語言（LISP 方言、函數式語言等）相比，OOP 語言沒有獨特的優勢，並且強加了不必要的複雜性。（勞倫斯·克魯布納）

我發現物件導向程式設計在技術上很脆弱。它試圖根據單一類型內不同的介面將世界分解為多個部分。為了處理實際問題，您需要多排序代數——跨多種類型的介面族。我發現物件導向程式設計在哲學上是不健康的。它指出一切都是物件。即使這是真的，也不是很有趣：說一切都是對像等於什麼也沒說。（亞歷山大·斯捷潘諾夫）

OOP 在大公司中的流行是由於「大量（且經常變化的）平庸程式設計師群體」。OOP 強加的紀律可以防止程式設計師造成「太多傷害」。（保羅·格雷厄姆）

物件導向程式將名詞放在首位。為什麼要採取如此極端的措施並把某個詞性推上神壇？為什麼一個概念優先於另一個概念？OOP 不可能突然使動詞對我們的思維變得不那麼重要。這是一個奇怪的傾斜的觀點。（史蒂夫葉格）

Clojure 的創建者 Rick Hickey 將物件系統描述為現實世界的極其簡化的模型。他強調 OOP 無法正確建模時間，當多執行緒在程式中變得普遍時，這會產生巨大的問題。Eric S. Raymond 是一位 Unix 程式設計師和開源軟體倡導者，他對 OOP 是「唯一解決方案」的說法持批評態度，並寫道 OOP 鼓勵多層程序，這阻礙了透明度。作為相反的方法，Raymond 舉了 Unix 和 C 的例子。

連結

作者：瑪格麗特·勞斯@WhatIs.com 維基百科！（俄文版） 繼承是多態性 SOLID（物件導向設計）（俄文版） 單一責任原則反對 OOPS 的爭論（俄文版） 什麼是 OOPS（沒有炒作） 翻譯：Varygin D.V.