Was ist schließlich die Definition von Objektorientierung?

Einführung

Das Paradigma der Objektorientierung ist sicherlich eines der relevantesten Themen in der Programmierung und findet sich in mehreren der Best Practices der Branche wie SOLID, GoF Design Patterns oder Object Calhistenics und sogar in äußerst beliebten Sprachen wie Java , C#, Ruby, PHP, JavaScript usw. Und angesichts dieser Relevanz ist es auch Gegenstand mehrerer Debatten sowohl in Online-Diskussionen als auch in der Wissenschaft selbst.

Eine der Hauptkontroversen rund um das Paradigma wäre: Was wäre Objektorientierung eigentlich? Da sich niemand darüber einig ist, was es bedeutet, ist dies der Kern des Problems bei verschiedenen Arten von Internetstreitigkeiten, beispielsweise wenn jemand behauptet, dass seine Sprache wirklich objektorientiert ist, andere jedoch nicht, oder dass eine bestimmte Sprache nicht wirklich objektorientiert ist. orientiert usw.

Was auf den ersten Blick albern erscheinen mag, aber dahinter steckt ein verstecktes Problem, nämlich die Tatsache, dass es wirklich keine formale Definition dafür gibt, was Objektorientierung wäre. Wenn wir also etwas kritisieren, das mit dem Paradigma zusammenhängt, können wir nicht wirklich sicher sein, ob es fair ist oder nicht, da niemand weiß, worum es in der Wahrheit eigentlich geht, da dies nur zu einer Debatte führen wird, in der beide Parteien die andere beschuldigen können einen Strohmann anzugreifen, weil er mit der Definition dessen, worüber er debattiert, nicht einverstanden ist, was dazu führt, dass er über verschiedene Dinge spricht, während er darüber nachdenkt, über dasselbe zu reden.

Dies geschieht, weil es nicht auf einer formalen Grundlage beruht, die als primäre Quelle von Diskussionen identifiziert werden kann, wie etwa dem strukturierten/prozeduralen Paradigma – das sich aus dem Boehm-Jacopini-Theorem und dem Artikel „Go-to-Aussage gilt als schädlich“ ergibt – oder aus dem Funktionalen, das aus der Lambda-Kalküle hervorgeht, im Gegenteil, technisch gesehen hat es zwei verschiedene Ursprünge, was die Sache sehr schwierig macht, schließlich ist es schwierig, überhaupt zu sagen, welche die erste objektorientierte Sprache war und ob sie es war Simula oder Smalltalk.

Wenn Sie noch keine Berührungspunkte mit dem Thema haben, finden Sie vielleicht alles, was ich hier beschreibe, etwas seltsam, schließlich lernen wir alle etwas über Objektorientierung, wir verwenden täglich Worte, um zu kommunizieren, und alles scheint normal zu laufen , kein Lärm in der Kommunikation, oder?

Sie denken vielleicht sogar, dass es sehr einfach ist, denn selbst wenn wir uns verschiedene Quellen ansehen, wie zum Beispiel ein allgemeines Tutorial im Internet, Wikipedia, oder sogar wenn wir eine formelle Ausbildung absolvieren (wie zum Beispiel einen technischen Kurs oder eine Hochschule), Wir werden sehr ähnliche Definitionen finden wie etwas, das ich die 4 Säulen der Objektorientierung nenne:

• Abstraktion;
• Einkapselung;
• Vererbung;
• Polymorphismus.

Aber das erzählt eigentlich nur einen Teil der Geschichte, denn wie ich bereits erwähnt habe, gibt es tatsächlich zwei verschiedene Schulen des objektorientierten Denkens, eine, die aus der in Simula geschaffenen Tradition hervorgegangen ist und durch C++ entwickelt und populär gemacht wurde, und eine andere, die in der von Smalltalk geschaffenen Tradition wuchs.

Auch wenn wir die Gewinnerseite der Geschichte in der Tradition von C++ akzeptieren können (da die überwiegende Mehrheit der als OO betrachteten Sprachen derzeit seinen Ideen mehr folgt als denen von Smalltalk), ist dies das Erbe von Simula, das sich in entwickelt hat Bei den 4 Säulen besteht kein Konsens darüber, ob es genau diese 4 sind oder ob sie wirklich 4 sein sollten. Zum Beispiel:

• Der Schöpfer der C++-Sprache selbst erwägt eine Definition, die nur drei Säulen hat (Abstraktion, Vererbung und Polymorphismus);
• Die Eiffel-Sprache berücksichtigt einen weiteren Satz von 6 Prinzipien (Klassen, Behauptungen, Generizität, Vererbung, Polymorphismus und dynamische Bindung);
• Der Schöpfer der Smalltalk-Sprache sagt, dass das, was er meinte, als er den Begriff prägte, nichts mit dem zu tun hat, was wir derzeit verwenden, und beschreibt, dass es tatsächlich auf drei Prinzipien hinausläuft (Message Passing, Encapsulation und Extreme Late-binding of all). Dinge);
• Die Ada-Sprache definiert nur drei Prinzipien (Kapselung, Vererbung und Polymorphismus);
• Die Selbstsprache basiert auf drei Ideen (Prototypen, Slots und Verhaltensweisen), die trotz anderer Namen äquivalent zu Begriffen sind, die in anderen Definitionen verwendet werden (Vererbung, Felder und Nachrichtenaustausch);
• Die Java-Sprache definiert 5 Konzepte (Kapselung, Felder, Vererbung, Methoden und Objekte);
• Die C#-Sprache folgt den 4 Säulen;
• Der Schöpfer der Simula-Sprache gibt zu, dass es keine konkrete Definition gibt, zitiert jedoch einige Konzepte, die seiner Meinung nach in Sprachen üblich sind, die als objektorientiert gelten (Objekte, Klassen, Vererbung, Polymorphismus);
• Die Python-Sprache nennt 4 Konzepte als objektorientiert (Klassen, Objekte, Vererbung und Polymorphismus);
• Die Ruby-Sprache behauptet, der Smalltalk-Definition zu folgen, mit großem Schwerpunkt auf der Idee, dass alles ein Objekt sein sollte, und dem Nachrichtenaustausch;
• Die PHP-Sprache hat keine offizielle Definition der Objektorientierung, aber wir können aus den Merkmalen, die sie als objektorientiert darstellt, ableiten, dass sie so etwas wie den 4 Säulen folgt;
• Die Objective-C-Sprache hat keine offizielle Definition der Objektorientierung, aber ihr Handbuch schlägt die folgende Kombination von Konzepten vor (alles ist ein Objekt, Klassen, Nachrichtenübermittlung, Kapselung, Vererbung und Polymorphismus);
• Die MDN-Website berücksichtigt in ihrem Abschnitt über die JavaScript-Sprache drei Konzepte (Klassen und Objekte, Vererbung und Kapselung);
• Grady Booch, Autorin des Buches Object-Oriented Analysis and Design With Applications, definiert 7 Prinzipien (Abstraktion, Kapselung, Modularität, Hierarchie, Typisierung, Parallelität und Persistenz);
• GoF (Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides) zitiert in ihrem Buch Design Patterns: Elements of Reusable Object-Oriented Software Kapselung, Vererbung und Polymorphismus als „Entwurfsmuster“ in einem Verfahren Sprache;
• Peter Van Roy beschreibt in seinem Buch „Concepts, Techiniques, and Models of Computer Programming“ OO in vier Elementen (Objekte wie Abstraktionsmechanismus, expliziter Zustand, Polymorphismus und Vererbung);
• ISO/IEC 2382 Artikel 2122503, der einer formalen Definition am nächsten kommt, berücksichtigt 6 Prinzipien (Abstraktion, Kapselung, Vererbung, Polymorphismus, Nachrichtenaustausch und dynamische Bindung );
• Jegor Bugayenko definiert es durch ein von ihm erstelltes formales Modell namens Phi-Kalkül, implementiert in seiner EOLANG-Sprache;
• usw....

Eine Perspektive definieren

Auf diese Weise argumentiert Bjarne Stroustrup (Erfinder von C++) in seiner Definition der Objektorientierung:

Jede Definition von „Objektorientierung“ sollte historisch akzeptabel sein. Worte dienen nur der Kommunikation, sie bedeuten nur dann etwas, wenn wir uns auf eine Bedeutung einigen.

~ Bjarne Stroustrup, adaptiert aus dem Englischen in freier Übersetzung

Deshalb möchte ich einen ganzheitlichen Ansatz verfolgen (Analyse des Ganzen statt des Klangs der Teile), um zu analysieren, was für meine Definition berücksichtigt werden sollte. Dabei bewerte ich nach 4 Kriterien in der Reihenfolge ihrer Wichtigkeit:

1. Konzeptionelle Ausrichtung mit der definierten Perspektive;
2. Historische Relevanz;
3. Umsetzungen in der Praxis (die auch als Wahrnehmung des gesunden Menschenverstandes gelten);
4. Exklusivität für OO (das Ausmaß, in dem das Konzept als etwas Objektorientiertes identifiziert werden kann und nicht als etwas aus dem X- oder Y-Paradigma oder einem allgemeineren Konzept);

Beginnen wir damit, unseren Ausgangspunkt in der Geschichte zu definieren. Zuerst entscheiden wir, welche Seite wir als primäre Quelle wählen, und folgen dann mit den Absichten, was Objektorientierung von seinen Autoren als Grundlage für unsere Definition bedeuten soll Zusätzlich kann es als Vergleichsparameter verwendet werden, um zu beurteilen, welche Reihe von Grundsätzen sinnvoll darin enthalten ist.

在這個問題上，我喜歡Alan Kay 發明了「物件導向」而不是「物件」的觀點，所以我們的基礎將是他對物件導向的看法，我們可以用幾句話來總結：

只是一個溫和的提醒，我在上一次 OOPSLA 中努力提醒大家，Smalltalk 不僅僅是它的語法或類別庫，也不是關於類的。我很遺憾很久以前為這個主題創造了“對象”這個術語，因為它導致許多人關注更小的想法。

最重要的想法是「訊息傳遞」 - 這就是 Smalltalk/Squeak 的核心所在...

~ Alan Kay，改編自英文意譯

我想到了諸如生物細胞和/或網絡上的個體計算機之類的對象，它們只能通過消息進行通信（因此消息很早就出現了- 我們花了一段時間才了解如何足夠有效地用程式語言發送訊息有用）。

我想刪除資料。 B5000 幾乎透過其令人難以置信的硬體架構做到了這一點。我意識到整個細胞/計算機的隱喻會消除數據，而“我的數學背景讓我意識到每個物件都可能有多個與之相關的代數，並且可能存在這些代數族，而這些代數將非常有用。 「多態性」這個術語是後來才強加的（我認為是 Peter Wegner 提出的），而且不是很有效，因為它實際上來自函數的命名法，而我想要的不僅僅是函數。我發明了一個術語“通用性”來以近乎代數的方式處理通用行為。

我不喜歡 Simula I 或 Simula 67 繼承的方式（儘管我認為 Nygaard 和 Dahl 只是偉大的思想家和設計師）。因此，我決定放棄繼承作為內建功能，直到我更好地理解它。

~ Alan Kay，改編自英文意譯

POO 對我來說只是意味著訊息交換、本地資料保留以及狀態保護和隱藏，以及所有事物的極端

後期綁定。

~ Alan Kay，改編自英文意譯

由此我們可以得出結論，使用 Kay 的定義來看待物件導向程式的

視角如下：

程式被視為透過訊息交換進行通訊的物件網絡，其目的是透過避免資料、專注於互動來進行編程，以便一則訊息可以承載多種意義。

說到視角，這是Simula 的創建者在他們的《BETA 程式語言中的物件導向程式設計》一書中使用的部分來描述框架的概念框架，即描述我們如何看待框架的結構以某種範式編寫的程序，例如在過程編程的情況下，他們將其描述為：

程式的執行被視為操作變數的（部分有序）過程呼叫序列。

~ 尼加德 (Nygaard)，改編自英文意譯

功能性情況下：

程式被認為是一個數學函數，它描述了輸入和輸出之間的關係。

~ 尼加德 (Nygaard)，改編自英文意譯

物件導向：

程式的執行被視為實體模型，模擬世界真實或想像部分的行為。

~ 尼加德 (Nygaard)，改編自英文意譯

因此，即使我們的重點是Alan Kay 的定義，考慮到Krysten Nygaard 和Ole-Johan Dahl（Simula 的創建者）在面向對象語言中的功能方面做出的巨大貢獻，以及他的觀點已經過時了時間，考慮到幾乎每個現代教程仍然遵循這個故事，即對象代表現實世界的概念，甚至被形式化為抽象定義的一部分，我認為將他的觀點納入我們的最終定義是合適的

。

因此，如果可以提出將兩種傳統調和成統一定義的論點，從而尊重我們的整體分析方法，我會嘗試。

因此，由於它不一定是我們目前的定義所獨有的，我們可以透過以下方式增加它：

程式被視為物件網絡，這些物件是領域概念的表示，透過訊息交換進行通信，其目的是程式設計避免數據，專注於交互，以便訊息可以承載多種含義。它的整體結構類似於對世界真實或想像部分的行為的模擬。

可以考慮的一個因素是，這可能會引導人們專注於“較小的想法”，但正如我們之前承認的那樣，有必要認識到想法如何隨著時間的推移而演變，因為一個詞只有在人們理解它時才有價值它想傳達什麼，因此我相信這個觀點在維持艾倫·凱的最初目標和融入尼加德和達爾的對象系統的價值觀之間找到了足夠的平衡。

定義概念

對於目前的定義文本，我已經可以滿意了，這是我對本文提出的問題的回答，但我相信範式的完整定義應該包括它所代表的內容的“視角”程序的執行，以及與之相關的一組原則。

因此，我們可以說我們已經完成了一半，現在我們可以回到我之前給出的廣泛定義列表，尋找哪些原則適合我們的觀點，同時又不違背我們的基本願景（專注於交換信息） .

為此，我們再次回到我們的主要來源，Smalltalk 的 OO 原則：

• 交換訊息；
• 本地資料保留，以及狀態保護和隱藏；
• 極端後期綁定。

如果我們再次使用歷史相關性標準，可能有人會說，由於這些術語如今已不再使用（訊息交換除外），我們應該考慮使用4 個支柱，並且我再次相信，使用在這裡採取和解的方法將是兩全其美且不矛盾的：

• 交換訊息；
• 多態性；
• 封裝；
• 抽象；
• 繼承；

有選擇這5個原則的解釋：

訊息交換

訊息交換在OO的原始脈絡中是不可協商的事情，畢竟Alan Kay聲稱是範式的大思想，它最重要的概念，這就是為什麼所有其他概念必須有一些東西處理它。

它在實踐中的採用是相當可觀的，因為具有歷史相關性的語言，如Self、Objective-C 和Ruby 與這個概念保持著緊密的聯繫，並且Ruby 本身被認為是當今的主流語言，建立了出色的應用程式除了擁有非常活躍的社群之外，它就像github 本身一樣。

我想說，除了繼承和封裝之外，它是最具有OO 特性的概念之一，因為使用該術語的其他兩個實例（有目的的笑話）將在Actor 模型中，其中是一個數學模型形式邏輯，基本上與Alan Kay 的思想幾乎相同，但完全基於並發（像OO 這樣的東西對你們JS 開發人員來說是100% 異步的）。

多態性

這是一個滿足我們分析的所有標準的概念，因為正如Nygaard 和Dahl 所指出的，它幾乎存在於實現該範式的所有語言中，即使是隱式的（如果它支持繼承，支持也隱式支持多態性）。

它也與交換訊息的想法非常一致，因為這是使用它的自然好處。此外，它出現在 Alan Kay 的定義中（儘管他說他更喜歡通用性這個術語），畢竟後期綁定是語言中存在的進程的名稱
程式設計允許他們不將呼叫與特定程式碼關聯起來，而是根據上下文執行它（在物件導向的情況下是接收訊息的物件），這正是多態性的定義.

就大眾認知而言，這將是所列出的5 個概念中最重要的概念，甚至被Bob 叔叔定義為OO 的本質，而且，即使在不打算完全以物件導向程式設計的情況下，這被認為是構建一些想法（例如六邊形架構或乾淨架構）的基本塊的原則。

然而，這個概念並不是物件導向所獨有的，它是一個更通用的概念，存在於多個範式中，通常具有同一語言中不同類型的實作。儘管如此，可以說特定的子類型多態性是 OO 所獨有的，因為它是依賴語言執行繼承能力的類型。

封裝

如果您閱讀過我們關於該主題的文章（是的，我們喜歡在這裡討論定義），您就會知道「本地資料保留，以及狀態保護和隱藏」基本上是完整的定義封裝，所以概念對齊方面，和之前的一樣，這裡100%遵循這個原則。

雖然有些語言沒有提到封裝作為原則，但這個概念在它們中甚至有一半存在，即擁有對象的事實（或者像Java和Self的情況一樣，強調對像中字段的概念）表明它們有一種機制可以使資料及其函數（物件本身）僅在本地上下文中進行操作，另一方面，C++ 和Eiffel 等語言提供了保護和隱藏表單中狀態的機制存取修飾符(C++) 或斷言、前置條件、後置條件與不變量(Eiffel)。在 Java 中，我們甚至有一篇關於物件導向的最著名的文章，其中詳細討論了封裝的應用：為什麼 getter 和 setter 是邪惡的。

所以我想說，這是一個經過時間考驗已經非常成熟的原則，儘管它仍然會受到與多態性相同的批評，因為它不是一個專門與OO 相關的概念，因為它可以使用模組（類似於單例對象）或閉包來實現它，因為它們可以充當窮人的對象，但是，就像多態性一樣，該概念在面向對像中“具有獨特的風味”應用，因為本地數據保留機制是對象，而資訊隱藏是透過存取修飾符發生的，這是與範式廣泛相關的功能。

抽象

它不像其他4 個支柱那樣出現得那麼多，但是，與封裝類似，仍然可以隱式而不是顯式地感受到它的存在，因為除了Self 之外，所有提到的語言都有一種機制以類別的形式進行資料抽象化。

談到自我的問題，他非常強調物件本身和資訊的交換，我們可以利用這些來分析概念對齊的問題，在這種情況下，我會說程式設計透過訊息交換，用更現代的話來說（儘管概念並不完全相同）將與「介面程式設計」相同，即僅使用抽象進行編程，而不用擔心最終的實作實際上是什麼就像Alec Sharp 所著的《Smalltalk by Example: The Developer's Guide》一書中很好描述的方法一樣，它是「物件導向的程式設計方式」。

抽象與多態結合的思想允許每個訊息交換隱喻發揮作用，因為這個想法是沒有辦法僅透過查看訊息來知道執行程式碼的結果是什麼，之後它們都是抽象（就像在現代面向物件中讀取介面的方法時你無法知道事物將如何執行一樣），並且結果取決於在物件本身中找到的具體實現，因此執行可能會有所不同，具體取決於哪個物件回應該訊息。

在所有原則中，我想說抽像是排他性標準中最弱的，因為資料抽像是通用原則，高於Peter Van Roy 在他的《傻瓜程式設計範式》一文中所述的範式概念，儘管如此再次，我們處於與其他原則類似的情況，其中它使用類形式的極其特有的機制，這些機制被廣泛認為是面向對象的功能，因此認識到許多人認為該範式僅限於使用類（甚至忘記了對象，更糟的是，忘記了過程中的消息）。

遺產

她來這裡的目的與交換訊息的目的相反，如果交換訊息的公眾感知得分較低，但概念對齊度最高，則繼承對所選概念的概念對齊度最低（可以通過引用Alan Kay 只是為Smalltalk 添加了遺產，因為他並不真正知道它會被用來做什麼，但認為它可能有用），但除了非常高的歷史貢獻之外，它還擁有最大的公眾認知度。

首先，它是Simula的主要特性之一，在後Smalltalk時代，它被認為是OO的本質，儘管在GoF發表組合而不是繼承的思想後，這一點被完全扭轉了。

儘管如此，它是唯一與 OO 相關的概念，在許多情況下，它的存在足以將一種語言區分為物件導向的語言。唯一可能反對這一點的論點是Hoare 的記錄的想法，但正是它引發了Simula 中的繼承和產品類型，但這與繼承是一個非常不同的主題，並且如果你們也面臨著同樣的問題和爭議。

結論

終於有了視角和原則，所以我們最後的定義是：

物件導向的程式被視為物件的網絡，這些物件是領域概念的表示，透過訊息交換進行通信，其目的是程式設計避免數據，專注於交互，以便訊息可以攜帶幾個意思。其原則是訊息交換、多型、封裝、抽象化和繼承。其整體結構類似於對世界真實或想像部分的行為的模擬。

無論如何，這是我對文章標題中提出的問題的最終答案，整個研究工作量很大，所以我希望這篇文章至少能教你一些新東西，或者引發一些思考。

如果你同意或不同意我的定義，別忘了在評論中分享你的觀點，我們下次再見！

您可能感興趣的鏈接

• 關於程式設計範式的維基百科；
• 關於多態性的維基百科；
• C2 Wiki - 沒有人就 OO 是什麼達成一致；
• C2 Wiki - 物件導向程式設計；
• Stackoverflow - 「物件導向」術語的意思；
• EOLANG 和 Phi 微積分；
• 電腦程式設計的概念、技術與模型；
• 傻瓜程式設計範式；
• Smalltalk 範例；
• BETA 程式語言中的物件導向程式設計；
• 為什麼 C++ 不僅僅是一種物件導向的程式語言；
• Alan Kay 博士談「物件導向程式設計」的意義；
• 物件導向的誕生：模擬語言；
• 物件導向程式設計的兩大流派；
• ISO/IEC 2382:2015；
• SelfObjectModel;
• 自我手冊；
• 自我：簡單的力量；
• 動態對比靜態調度；
• （錯誤）OOP 的解釋；
• 新興物件用閉包建構一個簡單的物件系統；
• MOPping 建構一個簡單的元物件協定；
• 調度介面；
• Alan Kay 與 OO 程式設計；
• 艾倫·凱沒有發明物體；
• 原型與類別是：Re: Sun's HotSpot;
• 論電腦程式規範與組織的未來；
• 無資料程式設計；
• Smalltalk 的早期故事；
• Go-to 語句被認為是有害的；
• 伯姆-雅可比尼定理；
• 艾菲爾關於 OO;
• Devmedia 優於 OO；
• 關於 lambda 演算的維基百科；
• 艾達關於物件導向；
• Java 規格第三版；
• C# 優於 OO；
• Python 優於 OO；
• PHP 優於 OO;
• Ruby 文件；
• MDN 優於 OO；
• 物件導向的分析與設計及其應用；
• 設計模式書；
• 為什麼 getter 和 setter 是邪惡的；
• Clean Coder 部落格 - FP 與 FP喔；
• 關於演員模型的維基百科；
• 關於 Actor 模型的 Akka（程式語言）；
• 莊嚴地談論演員模型；

屁股：累了支持

Das obige ist der detaillierte Inhalt vonWas ist schließlich die Definition von Objektorientierung?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!