JavaScript 是真正的 OOP 語言嗎？

JavaScript物件導向還是不物件導向，這是個問題。好吧，這就是我們將要在這篇文章中討論的主題。

我知道，這個話題已經被討論過太多次了。但是，它總是被不斷地提及。每當Java或C#或任何其他OOP語言的開發人員與JavaScript接觸時，這些開發人員都會抱怨連連。他們說，用JavaScript工作簡直是一團亂，沒有型別，結構不合理，有些怪異，物件支援不給力，它絕對不是OOP語言。

其中有一些抱怨可能可以接受，但還有一些則是偏見，例如說JavaScript沒有型別因而它不是OOP語言的言論。關於後面一點，在出口論斷之前，你應該問自己：是什麼使程式語言成為物件導向的程式語言？

什麼是OOP？

OOP模式沒有正式的標準規範。沒有一個技術文件定義了什麼是OOP，什麼不是OOP。OOP定義主要基於早期研究人員，如Kristen Nygaard, Alan Kays, William Cook等人發表的論文中的常識。已經有很多人嘗試定義OOP以及一個可廣泛接受的定義來對程式語言進行分類，因為物件導向基於兩個要求：

• 通過物件建模問題的能力。
• 支援一些准許模組化和程式碼重用的原則。

為了滿足第一個要求，這種語言必須使開發人員能夠使用物件來描述現實並定義物件之間的關係，如下所示：

• 關聯：物件引用另一個獨立物件的能力。
• 聚合：物件嵌入一個或多個獨立物件的能力。
• 組合：物件嵌入一個或多個依賴物件的能力。

通常，如果語言支援以下原則，則能滿足第二個要求：

• 封裝：專注於資料和操縱程式碼的單一實體，並隱藏其內部細節的能力。
• 繼承：一個物件從一個或多個其他物件獲取某些或所有要素的機制。
• 多型：根據資料型別或結構不同地處理物件的能力。

滿足這些要求的語言我們通常將其歸類為為物件導向的。

JavaScript和OOP

所以現在我們知道OOP語言應該是什麼樣子的了。那麼，我們可以證明JavaScript是一種OOP語言嗎？我們們試試吧。

我們知道，JavaScript物件支援關聯，聚合和組合的能力並不強勁。請看以下程式碼：

在上面的程式碼中，你可以找到一個組合（address屬性）的示例，一個關聯（parent屬性）的示例和一個聚合（employees屬性）的示例。

至於封裝，JavaScript物件是支援資料和函式的實體，但它們沒有高階的本地支援來隱藏內部細節。JavaScript物件不關心隱私。如果不謹慎的話，所有的屬性和方法都可以公開訪問。但是，我們可以應用若干技術來定義物件的內部狀態，並保護物件以防外部訪問：使用getter和setter來利用閉包。

通過所謂的原型繼承，JavaScript在基本層中支援繼承。即使有些開發人員認為它有點簡單，但JavaScript的繼承機制是完全有效的，並允許你得到與大多數公認的OOP語言相同的結果。任憑你怎麼想，JavaScript有一個機制，通過這個機制“一個物件從一個或多個其他物件獲取一些或所有的功能”，這就是繼承。

有多型性的挑戰似乎更加困難，因為許多人把這個概念與資料型別聯絡起來。實際上，多型性涉及程式語言的許多方面，並且不僅僅是與OOP語言有關。通常它涉及諸如泛型、過載和結構子型別等條目。所有這些對於一種“簡單”和弱型別的語言——JavaScript——來說似乎不堪重負。然而事實並非如此：在JavaScript中，我們可以通過若干方式實現不同型別的多型，也許我們在不知不覺中已經做過很多次了。

沒有類的OOP

“好吧，但話說回來，JavaScript沒有類。”

許多開發人員認為JavaScript缺乏類的概念，而沒有將JavaScript視為一種真正的物件導向的語言，因為它不強制符合OOP原則。

但是，我們可以看到，在非正式的定義中，並沒有明確提及類。誠然，物件需要特性和原理。但類並非真正的要求，只是有時，類是一種抽象具有公共屬性的物件集的簡便方法而已。因此，即使一種語言的支援物件沒有類，它也可以是物件導向的語言，例如JavaScript。

此外，OOP原則的目的旨在得到支援。為了在語言中進行程式設計，OOP原則不應該是強制規定的。開發人員可以選擇使用允許他建立物件導向程式碼的構造，也可以選擇不使用。許多人批評JavaScript是因為開發人員可以編寫違反OOP原則的程式碼。但這只是程式設計師的選擇，而不是語言的限制。其他的程式語言也會發生這樣的事情，如C ++。

所以，我們可以得出這樣一個結論，缺乏抽象類並允許開發人員自由使用或不使用支援OOP原理的功能，並非認定JavaScript是OOP語言的真正障礙。