Objekt orientierte Programmierung

"Objektorientiert" leitet hier weiter. Für andere Bedeutungen von Objektorientierten siehe Objektorientierung.
"Objektorientierte Programmiersprache" leitet hier weiter. Für eine Liste objektorientierter Programmiersprachen siehe siehe Liste der objektorientierten Programmiersprachen.

Objekt orientierte Programmierung (Oop) ist ein Programmierparadigma Basierend auf dem Konzept von "Objekte", was enthalten kann Daten und Code: Daten in Form von Felder (oft bekannt als als Attribute oder Eigenschaften) und Code in Form von Verfahren (oft bekannt als Methoden).

Ein gemeinsames Merkmal von Objekten ist, dass Verfahren (oder Methoden) an sie beigefügt sind und auf die Datenfelder des Objekts zugreifen und ändern können. In dieser Marke von OOP gibt es normalerweise einen besonderen Namen wie z. this oder self Wird verwendet, um sich auf das aktuelle Objekt zu beziehen. In OOP werden Computerprogramme entworfen, indem sie aus Objekten herausgebracht werden, die miteinander interagieren.[1][2] OOP -Sprachen sind vielfältig, aber die beliebtesten sind Klassenbasierte, was bedeutet, dass Objekte sind Instanzen von Klassen, die auch ihre bestimmen Typen.

Viele der am häufigsten verwendeten Programmiersprachen (wie C ++, Java, Python usw.) sind Multi-Paradigma und sie unterstützen eine objektorientierte Programmierung in einem größeren oder weniger Grad, typischerweise in Kombination mit Imperativ, Verfahrensprogrammierung. Zu den signifikanten objektorientierten Sprachen gehören:JavaAnwesendC ++AnwesendC#AnwesendPythonAnwesendRAnwesendPhpAnwesendVisual Basic.netAnwesendJavaScriptAnwesendRubinAnwesendPerlAnwesendSimscriptAnwesendObjekt PascalAnwesendZiel cAnwesendPfeilAnwesendSchnellAnwesendScalaAnwesendKotlinAnwesendCommon LispAnwesendMatlab, undSmalltalk.

Geschichte

Uml Notation für eine Klasse. Diese Schaltflächenklasse hat Variablen für Daten und Funktionen. Durch die Vererbung kann eine Unterklasse als Teilmenge der Schaltflächenklasse erstellt werden. Objekte sind Fälle einer Klasse.

Terminologie auf "Objekte" und "orientiert" im modernen Sinne der objektorientierten Programmierung trat zum ersten Mal auf MIT In den späten 1950er und frühen 1960er Jahren. In der Umgebung der künstliche Intelligenz Gruppe, bereits 1960, könnte sich "Objekt" auf identifizierte Elemente beziehen (LISPELN Atome) mit Eigenschaften (Attributen);[3][4] Alan Kay Später zitierte ein detailliertes Verständnis der Lisp -Interna als starker Einfluss auf sein Denken im Jahr 1966.[5]

Ich dachte an Objekte wie biologische Zellen und/oder einzelne Computer in einem Netzwerk, nur in der Lage, mit Nachrichten zu kommunizieren nützlich).

Alan Kay, [5]

Ein weiteres frühes MIT -Beispiel war Sketchpad erstellt von Ivan Sutherland 1960–1961; Im Glossar des technischen Berichts von 1963 definierte Sutherland die Vorstellungen von "Objekt" und "Instanz" (mit dem von "Master" oder "Definition" abgedeckten Klassenkonzept), wenn auch auf grafische Interaktion spezialisiert.[6] Auch ein MIT Algol Die Version, AED-0, stellte einen direkten Zusammenhang zwischen Datenstrukturen ("Plexes", in diesem Dialekt) und den Verfahren her, die das vorstellte, was später als "Nachrichten", "Methoden" und "Mitgliederfunktionen" bezeichnet wurden.[7][8]

Simula Einführte wichtige Konzepte, die heute ein wesentlicher Bestandteil der objektorientierten Programmierung sind, wie z. Klasse und ObjektErbschaft und Dynamische Bindung.[9] Die objektorientierte Simula-Programmiersprache wurde hauptsächlich von Forschern verwendet Physische Modellierung, wie Modelle, um die Bewegung von Schiffen und deren Inhalt durch Frachthäfen zu studieren und zu verbessern.[9]

In den 1970er Jahren die erste Version der Smalltalk Die Programmiersprache wurde bei entwickelt Xerox Parc durch Alan Kay, Dan Ingalls und Adele Goldberg. SmallTalk-72 beinhaltete eine Programmierumgebung und war dynamisch getipptund zunächst war interpretiert, nicht zusammengestellt. SmallTalk wurde für die Anwendung der Objektorientierung in der Umgebung auf Sprachebene und seiner grafischen Entwicklungsumgebung bekannt. SmallTalk durchlief verschiedene Versionen und das Interesse an der Sprache wuchs.[10] Während SmallTalk von den in Simula 67 eingeführten Ideen beeinflusst wurde, wurde es als voll dynamisches System entwickelt, bei dem Klassen erstellt und dynamisch geändert werden konnten.[11]

In den 1970er Jahren beeinflusste SmallTalk die Lisp -Community zu integrieren Objektbasierte Techniken das wurden den Entwicklern über die vorgestellt Lisp -Maschine. Experimentieren mit verschiedenen Erweiterungen zu Lisp (wie Schleifen und Flavors Einführung Mehrfacherbe und Mischungen) führte schließlich zur Gemeinsames Lisp -Objektsystem, die funktionale Programmierung und objektorientierte Programmierung integriert und eine Erweiterung über a ermöglicht Metaobjektprotokoll. In den 1980er Jahren gab es einige Versuche, Prozessorarchitekturen zu entwerfen, die die Hardware -Unterstützung für Objekte im Speicher beinhalteten, diese waren jedoch nicht erfolgreich. Beispiele sind die Intel IAPX 432 und die Linn Smart Rekonst.

1981 bearbeitete Goldberg die Augustausgabe von August von Byte MagazineEinführung von SmallTalk und objektorientiertem Programmieren an ein breiteres Publikum. 1986 die Verband für Rechenmaschinen organisierte die erste Konferenz über objektorientierte Programmierung, Systeme, Sprachen und Anwendungen (Oopsla), das unerwartet von 1.000 Menschen besucht wurde. Mitte der 1980er Jahre Ziel c wurde entwickelt von Brad Cox, der SmallTalk bei benutzt hatte Itt Inc., und Bjarne Stroustrup, der Simula für seine Doktorarbeit verwendet hatte C ++.[10] 1985,, Bertrand Meyer produzierte auch das erste Design der Eiffeltelsprache. Eiffel konzentriert sich auf Softwarequalität und ist eine rein objektorientierte Programmiersprache und eine Notation, die den gesamten Software-Lebenszyklus unterstützt. Meyer beschrieb die Eiffel -Softwareentwicklungsmethode, basierend auf einer kleinen Anzahl von Schlüsselideen aus Software -Engineering und Informatik, in Objektorientierte Softwarekonstruktion. Wesentlich für den Qualitätsfokus von Eiffel ist Meyers Zuverlässigkeitsmechanismus, Entwurf durch Vertrag, was ein wesentlicher Bestandteil sowohl der Methode als auch der Sprache ist.

Das Tiobe Popularitätsindex für Programmiersprache Grafik von 2002 bis 2018. In den 2000er Jahren die objektorientierte Java (blau) und die prozedural C (Schwarz) kämpfte um die oberste Position.

In den frühen und Mitte der neunziger Jahre entwickelte sich objektorientierte Programmierung als dominierende Programmierung Paradigma Bei der Programmiersprachen, die die Techniken unterstützen, wurden weit verbreitet. Dazu gehörten visuell Foxpro 3.0,[12][13][14] C ++,[15] und Delphi. Seine Dominanz wurde durch die steigende Popularität von weiter verbessert Grafische Benutzeroberflächen, die stark auf objektorientierte Programmierungstechniken beruhen. Ein Beispiel für eine eng verwandte dynamische GUI -Bibliothek und OOP -Sprache finden Sie in der Kakao Frameworks auf Mac OS X, geschrieben in Ziel c, eine objektorientierte, dynamische Messaging-Erweiterung auf C basierend auf SmallTalk. OOP -Toolkits verbesserten auch die Popularität von ereignisgesteuerte Programmierung (Obwohl dieses Konzept nicht auf OOP beschränkt ist).

Bei Eth Zürich, Niklaus Wirth und seine Kollegen hatten auch Themen untersucht wie Datenabstraktion und Modulare Programmierung (Obwohl dies in den 1960er Jahren oder früher in gemeinsam verwendet wurde). Modula-2 (1978) umfassten beide und ihr nachfolgendes Design. Oberon, beinhaltete einen unverwechselbaren Ansatz für Objektorientierung, Klassen und dergleichen.

Objektorientierte Funktionen wurden zu vielen bisher vorhandenen Sprachen hinzugefügt, einschließlich Ada, BASIC, Forran, Pascal, und Cobol. Das Hinzufügen dieser Funktionen zu Sprachen, die ursprünglich nicht für sie konzipiert waren, führte häufig zu Problemen mit Kompatibilität und Wartbarkeit von Code.

In jüngerer Zeit sind eine Reihe von Sprachen entstanden, die in erster Linie objektorientiert sind, aber auch mit der prozeduralen Methodik vereinbar sind. Zwei solche Sprachen sind Python und Rubin. Die wahrscheinlich kommerziell wichtigsten jüngsten objektorientierten Sprachen sind Java, entwickelt von Sun Microsystems, ebenso gut wie C# und Visual Basic.net (VB.NET), beide für Microsoft's entwickelt .NETZ Plattform. Jedes dieser beiden Frameworks zeigt auf seine Weise den Vorteil der Verwendung von OOP, indem eine Abstraktion aus der Implementierung erstellt wird. VB.NET- und C# unterstützen die Vererbung des Cross-Language-Vererbung und ermöglichen Klassen, die in einer Sprache definiert werden, um Unterklassenklassen in der anderen Sprache zu definieren.

Merkmale

Objektorientierte Programmierung verwendet Objekte, aber nicht alle zugehörigen Techniken und Strukturen werden direkt in Sprachen unterstützt, die behaupten, OOP zu unterstützen. Es führt Operationen in Operanden aus. Die unten aufgeführten Funktionen sind unter den Sprachen üblich, die als stark klassen- und objektorientiert angesehen werden (oder Multi-Paradigma mit OOP -Unterstützung) mit bemerkenswerten Ausnahmen erwähnt.[16][17][18][19]

Siehe auch: Vergleich der Programmiersprachen (objektorientierte Programmierung) und Liste der objektorientierten Programmierbegriffe

Mit Nicht-Oop-Sprachen geteilt

Modulare Programmierung Der Support bietet die Möglichkeit, Verfahren in Dateien und Module für organisatorische Zwecke zu gruppieren. Module sind Namespace Daher in Konflikt in einem Modul im Widerspruch zu einem Verfahren oder einer Variablen, die denselben Namen in einer anderen Datei oder einem anderen Modul teilen.

Objekte und Klassen

Sprachen, die die objektorientierte Programmierung (OOP) unterstützen Nachlass Für die Wiederverwendung und Erweiterbarkeit der Code in Form von beiden Klassen oder Prototypen. Diejenigen, die Klassen verwenden, unterstützen zwei Hauptkonzepte:

  • Klassen - Die Definitionen für das Datenformat und die verfügbaren Verfahren für einen bestimmten Typ oder eine bestimmte Klasse von Objekten; Kann auch Daten und Verfahren (so genannte Klassenmethoden) selbst enthalten, d. H. Klassen enthalten die Datenmitglieder und Mitgliederfunktionen
  • Objekte - Klassenfälle

Objekte entsprechen manchmal Dingen in der realen Welt. Beispielsweise kann ein Grafikprogramm Objekte wie "Circle", "Square", "Menü" haben. Ein Online -Einkaufssystem kann Objekte wie "Einkaufswagen", "Kunde" und "Produkt" haben.[20] Manchmal repräsentieren Objekte abstraktere Entitäten wie ein Objekt, das eine offene Datei darstellt, oder ein Objekt, das den Dienst der Übersetzung von Messungen von den USA üblich zu Metrik erbringt.

Jedes Objekt soll ein sein Beispiel einer bestimmten Klasse (zum Beispiel könnte ein Objekt mit seinem Namen auf "Mary" eine Instanz des Klassenangestellten sein). Verfahren in objektorientierter Programmierung werden als bezeichnet als Methoden; Variablen sind auch als bekannt als Felder, Mitglieder, Attribute oder Eigenschaften. Dies führt zu den folgenden Begriffen:

  • Klassenvariablen - Gehören zur Klasse als Ganzes; Es gibt nur eine Kopie von jedem einzelnen
  • Instanzvariablen oder Attribute - Daten, die dem Individuum gehören Objekte; Jedes Objekt hat seine eigene Kopie von jedem einzelnen
  • Mitgliedsvariablen - bezieht sich sowohl auf die Klassen- als auch auf Instanzvariablen, die von einer bestimmten Klasse definiert werden
  • Klassenmethoden - gehören zur Klasse als Ganzes und haben Zugriff auf nur Klassenvariablen und Eingaben aus dem Verfahrensaufruf
  • Instanzmethoden - gehören zu Einzelne Objekteund haben Zugriff auf Instanzvariablen für das spezifische Objekt, das sie aufgerufen werden, Eingaben und Klassenvariablen

Objekte werden wie Variablen mit komplexer interner Struktur zugegriffen, und in vielen Sprachen sind effektiv Zeigerals tatsächliche Verweise auf eine einzelne Instanz des Objekts im Speicher in einem Haufen oder Stapel. Sie liefern eine Schicht von Abstraktion Dies kann verwendet werden, um interne von externem Code zu trennen. Der externe Code kann ein Objekt verwenden, indem er eine bestimmte Instanzmethode mit einem bestimmten Satz von Eingabeparametern aufruft, eine Instanzvariable lesen oder in eine Instanzvariable schreiben. Objekte werden erstellt, indem in der Klasse, die als a bekannt ist Konstrukteur. Ein Programm kann viele Fälle derselben Klasse erstellen, die es ausführt, die unabhängig funktionieren. Dies ist eine einfache Möglichkeit, dass dieselben Verfahren für verschiedene Datensätze verwendet werden.

Objektorientierte Programmierung, die Klassen verwendet Klassenbasierte Programmierung, während Prototypbasierte Programmierung Verwendet normalerweise keine Klassen. Infolgedessen wird signifikant unterschiedliche und dennoch analoge Terminologie verwendet, um die Konzepte von zu definieren Objekt und Beispiel.

In einigen Sprachen können Klassen und Objekte mit anderen Konzepten wie komponiert werden Züge und Mischungen.

Klassenbasierte VS-Prototypenbasiert

Im Klassenbasierte Sprachen das Klassen werden vorher definiert und die Objekte werden basierend auf den Klassen instanziiert. Wenn zwei Objekte Apfel und Orange werden aus der Klasse instanziiert ObstSie sind von Natur aus Früchte und es ist garantiert, dass Sie sie auf die gleiche Weise umgehen können. z.B. Ein Programmierer kann die Existenz derselben Attribute erwarten wie z. Farbe oder Sugar_Content oder is_ripe.

Im Prototypbasierte Sprachen das Objekte sind die Haupteinheiten. Nein Klassen sogar existieren. Das Prototyp eines Objekts ist nur ein weiteres Objekt, mit dem das Objekt verknüpft ist. Jedes Objekt hat eines Prototyp Link (und nur eine). Neue Objekte können basierend auf bereits vorhandenen Objekten erstellt werden, die als Prototyp ausgewählt wurden. Sie können zwei verschiedene Objekte anrufen Apfel und Orange eine Frucht, wenn das Objekt Obst existiert und beides Apfel und Orange haben Obst als ihr Prototyp. Die Idee der Obst Klasse existiert nicht explizit, sondern als die Äquivalenzklasse der Objekte, die denselben Prototyp teilen. Die Attribute und Methoden der Prototyp sind delegiert an alle Objekte der Äquivalenzklasse, die durch diesen Prototyp definiert ist. Die Attribute und Methoden im Besitz Individuell kann das Objekt nicht von anderen Objekten derselben Äquivalenzklasse geteilt werden; z.B. das Attribut Sugar_Content kann unerwartet nicht vorhanden sein in Apfel. Nur Einzelvererbung kann durch den Prototyp implementiert werden.

Dynamischer Versand/Nachrichtenübergang

Es liegt in der Verantwortung des Objekts, nicht in einem externen Code, den Verfahrenscode auszuwählen, der als Antwort auf einen Methodenaufruf ausgeführt werden soll, normalerweise indem die Methode zur Laufzeit in einer mit dem Objekt verknüpften Tabelle nachgeschlagen wird. Diese Funktion ist bekannt als Dynamischer Versand. Wenn die Anrufvariabilität auf mehr als dem einzelnen Typ des Objekts beruht, auf dem sie aufgerufen wird (d. H. Mindestens ein weiteres Parameterobjekt ist an der Methode -Wahl), spricht man von einem Mehrfachversand.

Ein Methodenaufruf ist auch als bekannt als Nachrichtenübergang. Es wird als Nachricht (der Name der Methode und deren Eingabeparameter) konzipiert, die an das Objekt für den Versand übergeben werden.

Datenabstraktion

Datenabstraktion ist ein Entwurfsmuster, bei dem Daten nur für semantisch verwandte Funktionen sichtbar sind, um Missbrauch zu verhindern. Der Erfolg der Datenabstraktion führt zu einer häufigen Einbeziehung von Daten verstecken als Designprinzip in objektorientierter und reiner funktionaler Programmierung.

Wenn eine Klasse nicht zulässt, dass das Aufrufen des Codes auf interne Objektdaten zugreifen und nur durch Methoden Zugriff ermöglicht, ist dies eine starke Form der Abstraktion oder Informationen, die als Abstraktion bezeichnet werden. Einige Sprachen (z. Privatgelände Schlüsselwort und Bezeichnung von Methoden, die für die Verwendung nach Code außerhalb der Klasse mit dem vorgesehen sind Öffentlichkeit Stichwort. Methoden können auch öffentliche, private oder mittlere Ebenen entworfen werden, wie z. geschützt (Dies ermöglicht den Zugriff aus derselben Klasse und ihren Unterklassen, jedoch nicht von Objekten einer anderen Klasse). In anderen Sprachen (wie Python) wird dies nur durch Konvention durchgesetzt (zum Beispiel, Privatgelände Methoden können Namen haben, die mit einem beginnen unterstreichen).

Verkapselung

Die Kapselung verhindert, dass der externe Code mit dem internen Funktionieren eines Objekts befasst ist. Dies erleichtert Code RefactoringZum Beispiel, so dass der Autor der Klasse ändern kann, wie Objekte dieser Klasse seine Daten intern darstellen, ohne einen externen Code zu ändern (solange die "öffentliche" Methode auf die gleiche Weise funktioniert). Es ermutigt auch Programmierer, den gesamten Code zu setzen, der sich mit einem bestimmten Datensatz in derselben Klasse befasst, was ihn für ein einfaches Verständnis durch andere Programmierer organisiert. Einkapselung ist eine Technik, die ermutigt Entkopplung.

Zusammensetzung, Vererbung und Delegation

Objekte können andere Objekte in ihren Instanzvariablen enthalten. Dies ist bekannt als als Objektzusammensetzung. Beispielsweise kann ein Objekt in der Mitarbeiterklasse (entweder direkt oder über einen Zeiger) ein Objekt in der Adressklasse enthalten, zusätzlich zu seinen eigenen Instanzvariablen wie "First_Name" und "Position". Die Objektzusammensetzung wird verwendet, um "HAS-A" -Verziehungen darzustellen: Jeder Mitarbeiter hat eine Adresse, so .

Sprachen, die Klassen unterstützen, unterstützen fast immer Nachlass. Auf diese Weise können Klassen in einer Hierarchie arrangiert werden, die "iS-a-a-type" -Relationen darstellt. Zum Beispiel könnte der Klassenangestellte von der Klassenperson erben. Alle Daten und Methoden, die der übergeordneten Klasse verfügbar sind, werden auch in der untergeordneten Klasse mit den gleichen Namen angezeigt. Beispielsweise kann die Klassenperson Variablen "first_name" und "last_name" mit Methode "make_full_name ()" definieren. Diese werden auch im Klassenangestellten erhältlich sein, was die Variablen "Position" und "Gehalt" hinzufügen kann. Diese Technik ermöglicht eine einfache Wiederverwendung der gleichen Verfahren und Datenträger und spiegelt potenziell reale Beziehungen auf intuitive Weise wider. Anstatt Datenbanktabellen und Programmierunterroutinen zu verwenden, verwendet der Entwickler Objekte, mit denen der Benutzer besser vertraut ist: Objekte aus seiner Anwendungsdomäne.[21]

Unterklassen können die durch Superklassen definierten Methoden überschreiben. Mehrfacherbe ist in einigen Sprachen erlaubt, obwohl dies die Auflösungsüberschreibungen kompliziert machen kann. Einige Sprachen unterstützen besondere Unterstützung für MischungenObwohl in jeder Sprache mit mehreren Vererbung ein Mixin einfach eine Klasse ist, die keine Beziehung zwischen IS-A-A-Typ darstellt. Mixins werden typischerweise verwendet, um mehreren Klassen dieselben Methoden hinzuzufügen. Beispielsweise kann die Klasse unicodeConversionMixin eine Methode unicode_to_ascii () bereitstellen, wenn sie in den Klassen -FileReader- und Klassen -Webpagescraper enthalten sind, die keinen gemeinsamen übergeordneten übergeben.

Abstrakte Klassen kann nicht in Objekte instanziiert werden; Sie existieren nur zum Zweck der Vererbung in andere "konkrete" Klassen, die instanziiert werden können. In Java die Finale Schlüsselwort kann verwendet werden, um zu verhindern, dass eine Klasse unterklassifiziert wird.

Die Lehre von Zusammensetzung über die Vererbung Befürworter der Implementierung von Has-A-Beziehungen mit Komposition anstelle von Vererbung. Anstatt beispielsweise von der Klassenperson zu erben, könnte der Klassenangestellte jedem Mitarbeiterobjekt ein internes Personenobjekt geben, das dann die Möglichkeit hat, sich vor dem externen Code zu verbergen, selbst wenn die Klassenperson über viele öffentliche Attribute oder Methoden verfügt. Einige Sprachen wie gehen Unterstützen Sie überhaupt keine Vererbung.

Das "Offener/geschlossener Prinzip"Befürworter, dass Klassen und Funktionen" für die Erweiterung geöffnet sein, aber für die Änderung geschlossen werden ".

Delegation ist ein anderes Sprachmerkmal, das als Alternative zur Vererbung verwendet werden kann.

Polymorphismus

Subtyping - eine Form von Polymorphismus - Wenn das Aufrufen von Code unabhängig sein kann, welche Klasse in der unterstützten Hierarchie, auf der sie operiert - der übergeordneten Klasse oder einer ihrer Nachkommen. In der Zwischenzeit kann sich der gleiche Betriebsname unter Objekten in einer Vererbungshierarchie anders verhalten.

Zum Beispiel werden Objekte vom Typ Kreis und Quadrat aus einer gemeinsamen Klasse, die als Form bezeichnet wird, abgeleitet. Die Zeichnungsfunktion für jede Art von Form implementiert das, was für das Zeichnen beim Aufrufen von Code gleichgültig der jeweiligen Art der gezogenen Form bleibt.

Dies ist eine andere Art von Abstraktion, die Code extern zur Klassenhierarchie vereinfacht und stark ermöglicht Trennung von Bedenken.

Offene Rekursion

In Sprachen, die unterstützen offene Rekursion, Objektmethoden können andere Methoden auf demselben Objekt aufrufen (einschließlich sich selbst), in der Regel ein spezielles Variable oder ein Schlüsselwort, das aufgerufen wurde Dies oder selbst. Diese Variable ist spät gebunden; Es ermöglicht eine in einer Klasse definierte Methode, um eine andere Methode aufzurufen, die später in einer Unterklasse definiert wird.

OOP Sprachen

Siehe auch: Liste der objektorientierten Programmiersprachen

Simula (1967) wird allgemein als die erste Sprache mit den primären Merkmalen einer objektorientierten Sprache anerkannt. Es wurde für die Herstellung geschaffen Simulationsprogramme, in welchem, was als Objekte bezeichnet wurde, war die wichtigste Informationsdarstellung. Smalltalk (1972 bis 1980) ist ein weiteres frühes Beispiel und das, mit dem ein Großteil der OOP -Theorie entwickelt wurde. In Bezug auf den Grad der Objektorientierung können folgende Unterscheidungen getroffen werden:

OOP in dynamischen Sprachen

In den letzten Jahren ist objektorientierte Programmierung besonders beliebt geworden Dynamische Programmiersprachen. Python, Power Shell, Rubin und Groovig sind dynamische Sprachen, die auf OOP -Prinzipien basieren Perl und Php Ich habe seit Perl 5 und Php 4 und hinzufügen objektorientierte Merkmale, und Coldfusion Seit Version 6.

Das Dokumentobjektmodell von Html, Xhtml, und Xml Dokumente im Internet haben Bindungen an die Bevölkerung JavaScript/ECMaskript Sprache. JavaScript ist vielleicht das bekannteste Prototypbasierte Programmierung Sprache, die das Klonen aus Prototypen einsetzt, anstatt von einer Klasse zu erben Klassenbasierte Programmierung). Eine andere Skriptsprache, die diesen Ansatz verfolgt, ist Lua.

OOP in einem Netzwerkprotokoll

Die Nachrichten, die zwischen Computern fließen, um Dienste in einer Client-Server-Umgebung anzufordern, können als Linearisierungen von Objekten entwickelt werden, die von Klassenobjekten definiert werden, die sowohl dem Client als auch dem Server bekannt sind. Beispielsweise würde ein einfaches linearisiertes Objekt aus einem Längenfeld, einem Codepunkt bestehen, der die Klasse identifiziert, und einem Datenwert. Ein komplexeres Beispiel wäre ein Befehl, der aus der Länge und dem Codepunkt des Befehls und den Werten besteht, die aus linearisierten Objekten bestehen, die die Parameter des Befehls darstellen. Jeder solche Befehl muss vom Server an ein Objekt gerichtet werden, dessen Klasse (oder Superklasse) den Befehl erkennt und den angeforderten Dienst bereitstellen kann. Clients und Server werden am besten als komplexe objektorientierte Strukturen modelliert. Verteilte Datenverwaltungsarchitektur (DDM) nahm diesen Ansatz und verwendete Klassenobjekte, um Objekte auf vier Ebenen einer formalen Hierarchie zu definieren:

  • Felder, die die Datenwerte definieren, die Nachrichten bilden, wie z. B. deren Länge, Codepunkt und Datenwerte.
  • Objekte und Sammlungen von Objekten ähneln, was in a gefunden werden würde Smalltalk Programm für Nachrichten und Parameter.
  • Manager ähnlich wie Ibm i Objekte, wie ein Verzeichnis zu Dateien und Dateien, die aus Metadaten und Datensätzen bestehen. Manager bieten konzeptionell Speicher- und Verarbeitungsressourcen für ihre enthaltenen Objekte.
  • Ein Client oder Server, der aus allen Managern besteht, die zur Implementierung einer vollständigen Verarbeitungsumgebung erforderlich sind und Aspekte wie Verzeichnisdienste, Sicherheit und Parallelitätskontrolle unterstützen.

Die anfängliche Version von DDM definierte verteilte Dateidienste. Es wurde später erweitert, um die Grundlage für die Grundlage zu sein Verteilte relationale Datenbankarchitektur (DRDA).

Designmuster

Herausforderungen des objektorientierten Designs werden durch mehrere Ansätze angegangen. Am häufigsten ist bekannt als die Entwurfsmuster von Gamma kodifiziert et al.. Im weiteren Sinne der Begriff "Designmuster"Kann verwendet werden, um auf ein allgemeines, wiederholbares Lösungsmuster auf ein häufig vorkommendes Problem im Softwaredesign zu verweisen. Einige dieser häufig vorkommenden Probleme haben Auswirkungen und Lösungen, die speziell für die objektorientierte Entwicklung sind.

Vererbung und Verhaltensuntertyp

Siehe auch: Objektorientiertes Design

Es ist intuitiv anzunehmen, dass die Vererbung a schafft semantisch "ist ein"Beziehung, und so zu schließen, dass Objekte, die aus Unterklassen instanziiert wurden sicher verwendet anstelle von denen, die aus der Superklasse instanziiert wurden. Diese Intuition ist in den meisten OOP -Sprachen leider falsch, insbesondere in allen, die es zulassen, veränderlich Objekte. Subtyp -Polymorphismus Wie durchgesetzt von der Geben Sie Checker ein In OOP -Sprachen (mit veränderlichen Objekten) können nicht garantiert werden Verhaltensuntertyp in jedem Kontext. Verhaltensuntertype ist im Allgemeinen nicht entschlossen, daher kann es nicht von einem Programm (Compiler) implementiert werden. Klassen- oder Objekthierarchien müssen sorgfältig gestaltet werden, wobei mögliche falsche Verwendungen berücksichtigt werden, die nicht syntaktisch erkannt werden können. Dieses Problem ist als das bekannt Liskov -Substitutionsprinzip.

Bande von vier Entwurfsmustern

Hauptartikel: Designmuster (Informatik)

Entwurfsmuster: Elemente wiederverwendbarer objektorientierter Software ist ein einflussreiches Buch, das 1994 von veröffentlicht wurde von Erich Gamma, Richard Helm, Ralph Johnson, und John Vlissides, oft humorvoll als "Bande von vier" bezeichnet. Neben der Erforschung der Fähigkeiten und Fallstricke der objektorientierten Programmierung beschreibt es 23 gängige Programmierprobleme und -muster zur Lösung. Ab April 2007 befand sich das Buch im 36. Druck.

Das Buch beschreibt die folgenden Muster:

Objektorientierung und Datenbanken

Hauptartikel: Objektrelationsimpedanz-Missverhältnis, Objektrelationskartierung, und Objektdatenbank

Beide objektorientierte Programmierung und Relationale Datenbankverwaltungssysteme (RDBMS) sind heute in der Software äußerst häufig. Seit relationale Datenbanken Speichern Sie keine Objekte direkt (obwohl einige RDBMS über objektorientierte Merkmale verfügen, um dies zu nähern), besteht die Bedürfnisse, die beiden Welten zu überbrücken. Das Problem der Überbrückung von objektorientierten Programmierzugriffs und Datenmustern mit relationalen Datenbanken ist bekannt als Objektrelationsimpedanz-Missverhältnis. Es gibt eine Reihe von Ansätzen, um dieses Problem zu bewältigen, aber keine allgemeine Lösung ohne Nachteile.[23] Einer der häufigsten Ansätze ist Objektrelationskartierung, wie in Ide Sprachen wie Visual Foxpro und Bibliotheken wie z. Java -Datenobjekte und Rubin auf Schienen' Aktiver Rekord.

Es gibt auch Objektdatenbanken Dies kann zum Ersetzen von RDBMS verwendet werden, aber diese waren technisch und kommerziell erfolgreich wie RDBMS.

Modellierung und Beziehungen realer Welt

OOP kann verwendet werden, um reale Objekte und Prozesse mit digitalen Gegenstücken zu verknüpfen. Nicht alle sind sich einig, dass OOP die direkte Mapping der realen Welt erleichtert (siehe Kritik Abschnitt) oder diese reale Mapping ist sogar ein würdiges Ziel; Bertrand Meyer argumentiert in Objektorientierte Softwarekonstruktion[24] dass ein Programm kein Modell der Welt ist, sondern ein Modell eines Teils der Welt; "Die Realität ist ein Cousin, der zweimal entfernt wurde". Gleichzeitig wurden einige Hauptbeschränkungen von OOP festgestellt.[25] Zum Beispiel die Circle-Elipse-Problem ist schwer zu handhaben mit OOPs Konzept von Nachlass.

Jedoch, Niklaus Wirth (die das jetzt bekannte Sprichwort populär gemacht hat als Wirths Gesetz: "Software wird schneller als Hardware schneller") sagte über OOP in seinem Papier, "gute Ideen durch das aussehende Glas", "dieses Paradigma spiegelt die Struktur der Systeme 'in der realen Welt" eng wider, und es ist deshalb also Gut geeignet, um komplexe Systeme mit komplexen Verhaltensweisen zu modellieren. "[26] (Kontrast Kussprinzip).

Steve Yegge und andere stellten fest, dass natürlichen Sprachen der OOP -Ansatz der streng Priorisierung fehlt Dinge (Objekte/Substantive) Vor Aktionen (Methoden/Verben).[27] Dieses Problem kann dazu führen, dass OOP verwickeltere Lösungen leistet als prozedurale Programmierung.[28]

OOP und Steuerfluss

OOP wurde entwickelt, um die zu erhöhen Wiederverwendbarkeit und Wartbarkeit von Quellcode.[29] Transparente Darstellung der Steuerfluss hatte keine Priorität und sollte von einem Compiler behandelt werden. Mit zunehmender Relevanz paralleler Hardware und Multithread -CodierungDie Entwicklung des transparenten Kontrollflusss wird wichtiger, was mit OOP schwer zu erreichen ist.[30][31][32][33]

Verantwortung- vs. datengetriebenes Design

Verantwortungsgetriebenes Design Definiert Klassen in Bezug auf einen Vertrag, dh eine Klasse sollte in Bezug auf eine Verantwortung und die Informationen definiert werden, die sie teilt. Dies wird von Wirfs-Brock und Wilkerson mit kontrastiert datengetriebenes Design, wo Klassen um die Datenstrukturen definiert werden, die gehalten werden müssen. Die Autoren sind der Ansicht, dass verantwortungsgetriebenes Design vorzuziehen ist.

Solide und erfassen Richtlinien

FEST ist eine mnemonische, die von Michael Feathers erfunden wurde, in der fünf Prinzipien für Software -Engineering -Design vorliegen:

FASSEN (Allgemeine Verantwortungszuweisung -Softwaremuster) ist ein weiterer Satz von Richtlinien, die von befürwortet werden Craig Larman.

Kritik

Das OOP -Paradigma wurde aus einer Reihe von Gründen kritisiert, einschließlich der Nichteinhaltung seiner erklärten Ziele der Wiederverwendbarkeit und Modularität.[34][35] und um einen Aspekt der Softwaredesign und -modellierung (Daten/Objekte) auf Kosten anderer wichtiger Aspekte (Berechnung/Algorithmen) zu überbilden.[36][37]

Luca Cardelli hat behauptet, dass OOP -Code "intrinsisch weniger effizient" ist als der prozessuale Code, dass OOP länger dauern kann und dass OOP -Sprachen "extrem schlechte Modularitätseigenschaften in Bezug auf Klassenerweiterung und Modifikation" haben und in der Regel äußerst komplex sind.[34] Der letztere Punkt wird von wiederholt von Joe Armstrong, der Haupterfinder von Erlang, wer wird zitiert: Sagus:[35]

Das Problem mit objektorientierten Sprachen ist, dass sie all diese implizite Umgebung haben, die sie mit ihnen herum tragen. Sie wollten eine Banane, aber was Sie bekommen haben, war eine Gorilla, die die Banane und den gesamten Dschungel hielt.

Eine Studie von Potok et al. hat keinen signifikanten Unterschied in der Produktivität zwischen OOP- und Verfahrensansätzen gezeigt.[38]

Christopher J. Date Es wurde festgestellt, dass der kritische Vergleich von OOP mit anderen Technologien, insbesondere relational, schwierig ist, da ein vereinbarter Upon und eine strenge Definition von OOP fehlt.[39] Datum und Darwen haben jedoch eine theoretische Grundlage für OOP vorgeschlagen, die OOP als eine Art anpassbar verwendet Typ System zu unterstützen RDBMS.[40]

In einem Artikel behauptete Lawrence Krubner, dass OP -Sprachen im Vergleich zu anderen Sprachen (Lisp -Dialekte, funktionale Sprachen usw.) keine einzigartigen Stärken aufweisen und eine schwere Belastung der nicht benötigten Komplexität verursachen.[41]

Alexander Stepanov vergleicht die Objektorientierung ungünstig mit generische Programmierung:[36]

Ich finde OOP technisch unangemessen. Es versucht, die Welt in Bezug auf Schnittstellen zu zersetzen, die von einem einzelnen Typ variieren. Um mit den tatsächlichen Problemen umzugehen, benötigen Sie multisortierte Algebren - Familien von Schnittstellen, die mehrere Typen umfassen. Ich finde OOP philosophisch unangemessen. Es behauptet, dass alles ein Objekt ist. Auch wenn es wahr ist, ist es nicht sehr interessant - zu sagen, dass alles ein Objekt überhaupt nichts sagt.

Paul Graham hat vorgeschlagen, dass die Popularität von OOP in großen Unternehmen auf "große (und sich häufig verändernde) Gruppen mittelmäßiger Programmierer zurückzuführen ist. Laut Graham verhindert die von OOP auferlegte Disziplin, dass ein Programmierer "zu viel Schaden anrichtet".[42]

Leo Brodie hat einen Zusammenhang zwischen der eigenständigen Natur von Objekten und einer Tendenz vorgeschlagen Doppelter Code[43] unter Verstoß gegen die Wiederhole dich nicht Prinzip[44] der Softwareentwicklung.

Steve Yegge bemerkte das im Gegensatz dazu Funktionelle Programmierung:[45]

Die objektorientierte Programmierung setzt die Substantive in erster Linie an. Warum sollten Sie zu solchen Längen gehen, um einen Teil der Rede auf ein Podest zu setzen? Warum sollte eine Art von Konzept Vorrang vor einer anderen haben? Es ist nicht so, als hätte OOP Verben plötzlich weniger wichtig für die Art und Weise, wie wir es tatsächlich denken. Es ist eine seltsam verzerrte Perspektive.

Reicher Hickey, Schöpfer von Clojure, beschrieben Objektsysteme als übermäßig simpistische Modelle der realen Welt. Er betonte die Unfähigkeit von OOP, die Zeit ordnungsgemäß zu modellieren, was immer problematischer wird, wenn Softwaresysteme gleichzeitiger werden.[37]

Eric S. Raymond, a Unix Programmierer und Quelloffene Software Advocate war kritisch gegenüber Behauptungen, die objektorientierte Programmierung als "eine wahre Lösung" darstellen, und hat geschrieben, dass objektorientierte Programmiersprachen tendenziell dickgeschichtete Programme fördern, die Transparenz zerstören.[46] Raymond vergleicht dies ungünstig mit dem Ansatz mit Unix und der C Programmiersprache.[46]

Rob Pike, ein Programmierer, der an der Schaffung von beteiligt ist UTF-8 und gehen, hat objektorientierte Programmierung genannt "die römische Zahlen des Computers "[47] und hat gesagt, dass OOP -Sprachen den Fokus häufig von der Fokus verändern Datenstrukturen und Algorithmen zu Typen.[48] Darüber hinaus zitiert er eine Instanz von a Java Professor, dessen "idiomatische" Lösung für ein Problem darin bestand, sechs neue Klassen zu erstellen, anstatt einfach a zu verwenden Nachschlagwerk.[49]

In Bezug auf Erbschaft, Bob Martin gibt an, dass verwandte Klassen, weil sie Software sind, nicht unbedingt die Beziehungen der Dinge teilen, die sie darstellen.[50]

Formelle Semantik

Siehe auch: Formale Semantik von Programmiersprachen

Objekte sind die Laufzeiteinheiten in einem objektorientierten System. Sie können eine Person, einen Ort, ein Bankkonto, eine Datentabelle oder ein beliebiges Element darstellen, das das Programm behandeln muss.

Es gab mehrere Versuche, die Konzepte zu formalisieren, die für die objektorientierte Programmierung verwendet wurden. Die folgenden Konzepte und Konstrukte wurden als Interpretationen von OOP -Konzepten verwendet:

Versuche, eine Konsensdefinition oder Theorie hinter Objekten zu finden, haben sich nicht sehr erfolgreich erwiesen (siehe jedoch Abadi & Cardelli, Eine Theorie der Objekte[52] Für formale Definitionen vieler OOP -Konzepte und -konstrukte) und häufig weitgehend. Zum Beispiel konzentrieren sich einige Definitionen auf mentale Aktivitäten und einige auf die Programmstrukturierung. Eine der einfacheren Definitionen ist, dass OOP die Verwendung von Datenstrukturen oder Arrays "MAP" verwendet, die Funktionen und Zeiger auf andere Karten enthalten können, alle mit einigen syntaktischer und Scoping -Zucker oben drauf. Die Vererbung kann durch Klonen der Karten durchgeführt werden (manchmal als "Prototyping" bezeichnet).

Siehe auch

Systeme

Modellierungssprachen

Verweise

  1. ^ Kindler, e.; Krivy, I. (2011). "Objektorientierte Simulation von Systemen mit ausgefeilter Kontrolle". Internationales Journal of General Systems: 313–343. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  2. ^ Lewis, John; Loftus, William (2008). Java Software Solutions Foundations of Programming Design 6. Aufl.. Pearson Education Inc. ISBN 978-0-321-53205-3., Abschnitt 1.6 "Objektorientiertes Programmieren"
  3. ^ McCarthy, J.; Brayton, R.; Edwards, D.; Fox, P.; Hodes, L.; Luckham, D.; Maling, K.; Park, D.; Russell, S. (März 1960). "LISP I Programmierer Handbuch" (PDF). Boston, Massachusetts: Künstliche Intelligenzgruppe, M.I.T. Berechnungszentrum und Forschungslabor: 88f. Archiviert von das Original (PDF) am 17. Juli 2010. In der örtlichen M.I.T. Patois, Assoziationslisten [von Atomsymbolen] werden ebenfalls als "Eigenschaftslisten" bezeichnet, und Atomsymbole werden manchmal als "Objekte" bezeichnet. {{}}: Journal zitieren erfordert |journal= (Hilfe)
  4. ^ McCarthy, John; Abrahams, Paul W.; Edwards, Daniel J.; Hart, Swapnil D.; Levin, Michael I. (1962). LISP 1.5 -Programmierhandbuch. MIT Press. p.105. ISBN 978-0-262-13011-0. Objekt - Ein Synonym für Atomsymbol
  5. ^ a b "Dr. Alan Kay über die Bedeutung von" objektorientiertes Programmieren "". 2003. Abgerufen 11. Februar 2010.
  6. ^ Sutherland, I. E. (30. Januar 1963). "Sketchpad: Ein grafisches Kommunikationssystem von Menschenmaschine". Technischer Bericht Nr. 296, Lincoln Laboratory, Massachusetts Institute of Technology über Defense Technical Information Center (stinet.dtic.mil). Archiviert von das Original am 8. April 2013. Abgerufen 17. Juli 2019.
  7. ^ Die Entwicklung der Simula -Sprachen, Kristen Nygaard, Ole-Johan Dahl, S.254 Uni-kl.ac.at
  8. ^ Ross, Doug. "Die erste Software -Engineering -Sprache". LCS/AI Lab. MIT Informatik und künstliche Intelligenzlabor. Abgerufen 13. Mai 2010.
  9. ^ a b Holmevik, Jan Rune (1994). "Simula zusammenstellen: Eine historische Studie der technologischen Genesis" (PDF). IEEE Annals of the History of Computing. 16 (4): 25–37. doi:10.1109/85.329756. S2CID 18148999. Archiviert von das Original (PDF) am 30. August 2017. Abgerufen 3. März 2018.
  10. ^ a b Bertrand Meyer (2009). Berührung der Klasse: Lernen, gut mit Objekten und Verträgen zu programmieren. Springer Science & Business Media. p. 329. Bibcode:2009tclp.book ..... m. ISBN 978-3-540-92144-8.
  11. ^ Kay, Alan. "Die frühe Geschichte von SmallTalk". Archiviert von das Original am 10. Juli 2008. Abgerufen 13. September 2007.
  12. ^ 1995 (Juni) visuell Foxpro 3.0, FoxPro entwickelt sich von einer prozeduralen Sprache zu einer objektorientierten Sprache. Visual FoxPro 3.0 führt einen Datenbankcontainer, nahtlose Client/Server -Funktionen, Unterstützung für ActiveX -Technologien sowie OLE -Automatisierung und Nullunterstützung ein. Zusammenfassung der Fox -Veröffentlichungen
  13. ^ FoxPro History -Website: FoxProhistory.org
  14. ^ 1995 Rezensentenhandbuch für Visual FoxPro 3.0: Dfpug.de
  15. ^ Khurana, Rohit (1. November 2009). Objektorientierte Programmierung mit C ++, 1E. ISBN 978-81-259-2532-3.
  16. ^ Deborah J. Armstrong. Die Quarks von objektorientierter Entwicklung. Eine Umfrage von fast 40 Jahren Computerliteratur, in der eine Reihe grundlegender Konzepte in der großen Mehrheit der Definitionen von OOP in absteigender Reihenfolge der Popularität festgestellt wurden: Vererbung, Objekt, Klasse, Kapselung, Methode, Nachrichtenüberwachung, Polymorphismus und Abstraktion.
  17. ^ John C. Mitchell, Konzepte in Programmiersprachen, Cambridge University Press, 2003, ISBN0-521-78098-5, S. 278. Listen: Dynamischer Versand, Abstraktion, Subtyp -Polymorphismus und Vererbung.
  18. ^ Michael Lee Scott, Programmiersprache Pragmatik, Edition 2, Morgan Kaufmann, 2006, ISBN0-12-633951-1, p. 470. Listet die Kapselung, Vererbung und dynamischer Versand auf.
  19. ^ Pierce, Benjamin (2002). Typen und Programmiersprachen. MIT Press. ISBN 978-0-262-16209-8., § 18.1 "Was ist objektorientierte Programmierung?" Listen: Dynamischer Absendung, Kapselung oder Multi-Methoden (Mehrfachversorgungs), Subtyp-Polymorphismus, Vererbung oder Delegation, offener Rekursion ("dieses"/"self")
  20. ^ Booch, Grady (1986). Software -Engineering mit ADA. Addison Wesley. p. 220. ISBN 978-0-8053-0608-8. Die vielleicht größte Stärke eines objektorientierten Entwicklungsansatzes ist, dass es einen Mechanismus bietet, der ein Modell der realen Welt erfasst.
  21. ^ Jacobsen, Ivar; Magnus Chrierson; Patrik Jonsson; Gunnar Overgaard (1992). Objektorientiertes Software -Engineering. Addison-Wesley ACM Press. pp.43–69. ISBN 978-0-201-54435-0.
  22. ^ "Die Smaragd -Programmiersprache". 26. Februar 2011.
  23. ^ Neward, TED (26. Juni 2006). "Das Vietnam der Informatik". Interoperabilität geschieht. Archiviert von das Original am 4. Juli 2006. Abgerufen 2. Juni 2010.
  24. ^ Meyer, zweite Ausgabe, p. 230
  25. ^ M.Trofimov, Ooop - die dritte "O" -Lösung: OP OP. Erste Klasse, OMG, 1993, vol. 3, Ausgabe 3, S.14.
  26. ^ Wirth, Nicklaus (2006). "Gute Ideen durch das aussehende Glas" (PDF). Computer. 39 (1): 28–39. doi:10.1109/mc.2006.20. S2CID 6582369. Archiviert von das Original (PDF) am 12. Oktober 2016. Abgerufen 2. Oktober 2016.
  27. ^ Yegge, Steve (30. März 2006). "Ausführung im Königreich der Substantive". Steve-yegge.blogspot.com. Abgerufen 3. Juli 2010.
  28. ^ Boronczyk, Timothy (11. Juni 2009). "Was ist los mit OOP". Zaemis.blogspot.com. Abgerufen 3. Juli 2010.
  29. ^ Ambler, Scott (1. Januar 1998). "Ein realistischer Blick auf die objektorientierte Wiederverwendung". DRDOBBS.com. Abgerufen 4. Juli 2010.
  30. ^ Shelly, ASAF (22. August 2008). "Fehler der objektorientierten Modellierung". Intel Software -Netzwerk. Abgerufen 4. Juli 2010.
  31. ^ James, Justin (1. Oktober 2007). "Multithreading ist ein Verb kein Substantiv". TechRepublic.com. Archiviert von das Original am 10. Oktober 2007. Abgerufen 4. Juli 2010.
  32. ^ Shelly, ASAF (22. August 2008). "Wie man: Multicore -Programmierung (Multiprocessing) visuelle C ++ -Klassentwurfsrichtlinien, Mitgliedsfunktionen". Support.microsoft.com. Abgerufen 4. Juli 2010.
  33. ^ Robert Harper (17. April 2011). "Einige Gedanken zum Unterrichten von FP". Existenzieller Typ Blog. Abgerufen 5. Dezember 2011.
  34. ^ a b Cardelli, Luca (1996). "Schlechte technische Eigenschaften objektorientierter Sprachen". ACM Comput. Überleben. 28 (4ES): 150 - ES. doi:10.1145/242224.242415. ISSN 0360-0300. S2CID 12105785. Abgerufen 21. April 2010.
  35. ^ a b Armstrong, Joe. Im Codierer bei der Arbeit: Überlegungen zum Programm des Programms. Peter Seibel, hrsg. Codersatwork.com Archiviert 5. März 2010 bei der Wayback -Maschine, Abgerufen am 13. November 2009.
  36. ^ a b Stepanov, Alexander. "Stlport: Ein Interview mit A. Stepanov". Abgerufen 21. April 2010.
  37. ^ a b Rich Hickey, JVM Languages ​​Summit 2009 Keynote, Sind wir schon da? November 2009.
  38. ^ Potok, Thomas; Mladen vouk; Andy Rindos (1999). "Produktivitätsanalyse der in einer kommerziellen Umgebung entwickelten objektorientierten Software" (PDF). Software: Übung und Erfahrung. 29 (10): 833–847. doi:10.1002/(sici) 1097-024x (199908) 29:10 <833 :: Aid-SPE258> 3.0.co; 2-P.. S2CID 57865731. Abgerufen 21. April 2010.
  39. ^ C. J. Datum, Einführung in Datenbanksysteme, 6th-Ed., Seite 650
  40. ^ C. J. Date, Hugh Darwen. Grundlage für zukünftige Datenbanksysteme: Das dritte Manifesto (2. Auflage)
  41. ^ Krubner, Lawrence. "Objektorientierte Programmierung ist eine teure Katastrophe, die enden muss". Smashcompany.com. Archiviert von das Original am 14. Oktober 2014. Abgerufen 14. Oktober 2014.
  42. ^ Graham, Paul. "Warum ARC nicht besonders objektorientiert ist". Paulgraham.com. Abgerufen 13. November 2009.
  43. ^ Brodie, Leo (1984). Weiterdenken (PDF). S. 92–93. Abgerufen 4. Mai 2018.
  44. ^ Hunt, Andrew. "Wiederhole dich nicht". Kategorie Extreme Programmierung. Abgerufen 4. Mai 2018.
  45. ^ "Steveys Blog Rants: Ausführung im Königreich der Substantive". Abgerufen 20. Mai 2020.
  46. ^ a b Eric S. Raymond (2003). "Die Kunst der Unix-Programmierung: UNIX- und objektorientierte Sprachen". Abgerufen 6. August 2014.
  47. ^ Pike, Rob (2. März 2004). "[9Fans] Re: Fäden: Nähabzeichen der Ehre auf einen Kernel". comp.os.plan9 (Mailingliste). Abgerufen 17. November 2016.
  48. ^ Pike, Rob (25. Juni 2012). "Weniger ist exponentiell mehr". Abgerufen 1. Oktober 2016.
  49. ^ Pike, Rob (14. November 2012). "Vor ein paar Jahren habe ich diese Seite gesehen". Archiviert von das Original am 14. August 2018. Abgerufen 1. Oktober 2016.
  50. ^ "Onkel Bob Solid Principles". Youtube.
  51. ^ Umfrage, Erik. "Subtyping und Vererbung für kategoriale Datentypen" (PDF). Abgerufen 5. Juni 2011.
  52. ^ a b Abadi, Martin; Cardelli, Luca (1996). Eine Theorie der Objekte. Springer-Verlag New York, Inc. ISBN 978-0-387-94775-4. Abgerufen 21. April 2010.

Weitere Lektüre

Externe Links