Warum stammen Klassen implizit nur aus der Objektklasse?

Question

Ich habe kein Argument, warum wir nur eine einzige universelle Klasse brauchen. Warum jedoch nicht zwei universelle Klassen, sagen wir ein Objekt und eine Antio -Object -Klasse. In der Natur und in der Wissenschaft finden wir das Konzept der Dualität - wie Energie & dunkle Energie; Männlich Weiblich; Plus minus; Multiplizieren & teilweise; Elektronen & Protonen; Integration & Ableitung; und in der festgelegten Theorie. Es gibt so viele Beispiele für den Dualismus, dass es eine Philosophie für sich ist. Bei der Programmierung selbst sehen wir Anti-Muster, die uns hilft, Arbeiten im Gegensatz zu der Verwendung von Designmustern auszuführen. Ich bin mir nicht sicher, aber die Nützlichkeit dieses Dualitätskonzepts kann bei der Schaffung von Müllsammlern liegen, die Antio -Objekte schaffen, die sich mit freien oder losen Objekten kombinieren, um sich selbst zu zerstören, und damit das Gedächtnis freigeben. Oder können Antio -Objekte zusammen mit Objekten arbeiten, um eine selbstmodifizierende Programmiersprache zu erstellen. Dies ermöglicht es uns, einen sicheren, selbst modifizierenden Code zu erstellen, evolutionäres Computing mit genetischer Programmierung durchzuführen und Code zu verbergen, um Reverse Engineering zu verhindern.

Wir nennen es objektorientierte Programmierung. Ist das ein einschränkender Faktor oder gibt es etwas Grundlegendes, um die Bildung von Programmiersprachen zu verstehen?

Answer 1

Dies ist nur eine Antwort, um die Frage im Titel zu beantworten.

Sprachen wie Java haben jede Klasse aus zwei Gründen aus dem Objekt.

Erstens, um die verfügbare Polymorphismus zu erhöhen. Dies war besonders erforderlich, bevor Generika in die Sprache hinzugefügt wurden. Ohne Objekt könnten Sammlungskurse nicht nützlich schreiben.

Zweitens gibt es viele Methoden, von denen Klassen erwartet werden oder nützlich sind und diese im Objekt gesammelt werden. Indem alle Klassen aus dem Objekt erben, werden alle Klassen dieselbe minimale Schnittstelle implementieren.

Wie in einem Kommentar erwähnt, hat C ++ keine Klasse wie Objekt. C ++ ist in vielerlei Hinsicht ungeteilt, daher sind die oben erwähnten Probleme nicht anwendbar. Außerdem bieten C ++ - Vorlagen viel Polymorphismus und werden zur Implementierung von Sammlungen verwendet.

Answer 2

Ich denke, die akzeptierte Antwort deckt so ziemlich die ursprüngliche Frage ab, aber ich möchte sie (wenn ich darf) leicht ergänzen, indem ich (ziemlich informell) ein paar Ideen zu den sekundären Fragen einwirft.

Aus Sicht der Vererbung verhindert nichts, dass die Klassenhierarchie mehrere Wurzeln hat. Wie von anderen Völkern hervorgeht, werden C ++ sowie viele OO -Sprachen die Ausdruckskraft nicht auf eine einzelne Wurzel -Vorfahrklasse einschränken.

Jedoch von a Typ theoretisch Sichtweise (erinnern Sie sich daran, dass Vererbung und Subtyping nicht dasselbe sind, daher tritt ich wahrscheinlich hier aus dem Rahmen der Hauptfrage), ein einzelner "Top" -Supertyp kann viel Sinn machen (abhängig von der Typtheorie von Kurs). Zum Beispiel gibt es in OCAML einen gemeinsamen Supertyp für alle Objekte (ob Klasseninstanzen oder unmittelbare Objekte), geschrieben < > Um zu bezeichnen, dass der Objekttyp leer ist, akzeptiert der IE keine Nachricht. Dies scheint in der Tat der allgemeinste Objekttyp, den wir definieren können, da wir nichts davon entfernen können, um ihn allgemeiner zu machen. In dieser Konzeption von Objekttypen gibt es daher notwendigerweise einen Supertyp für alle Objekte.

In Bezug auf das Dual des Wurzelobjekts trägt Scala eine Klasse, die genannt wird Nothing, was neugierig auch leer ist und der Subtyp aller anderen Klassen ist. Es kann nicht instanziiert werden, sondern hält genügend nützliches Semantik, um die leere Liste zu implementieren, die genannt wird Nil, und ist gleich zu List[Nothing] (Wie in Kommentaren hervorgehoben, ist es möglich, dass der Programmierer diesen Wert in den meisten Fällen nie direkt verwendet, was es anscheinend nicht so nützlich macht wie er ist). Nothing könnte als Dual des Wurzeltyps angesehen werden - genannt Any In Scala decken diese Typen jedoch nicht nur Klassen, sondern auch Primitive -Typen ab, so dass alles aufgerüstet werden kann Any, zum Beispiel.

Answer 3

Die Fähigkeit, Sammlungen zu definieren, die willkürliche Arten von Dingen enthalten können, ohne verschiedene Methoden für verschiedene Arten von Dingen zu definieren, ist sehr nützlich. Vorlagen in C ++ ermöglichen es einer einzelnen Quelldatei, Sammlungstypen zu definieren, die viele verschiedene Arten von Dingen enthalten können. Der Compiler muss jedoch den Code für alle verschiedenen Art von Dingen in der Sammlung duplizieren. Wenn man stattdessen fast alle Typen im System definiert, die von einem einzelnen Typ abgeleitet werden, kann eine Sammlung, die Verweise auf Dinge dieses Typs enthalten kann, in der Lage sein, Verweise auf Dinge von fast irgendeinem Typ zu halten.

Dieser Ansatz hat jedoch eine Einschränkung, dass er die Unterscheidungen zwischen Werten und Entitäten verwischt. Eine Referenz, die einen Wert durch die Identifizierung eines bestimmten Objekts zusammenfasst, kann durch eine Referenz auf eine Kopie dieses Objekts ersetzt werden, ohne seine Semantik zu ändern. Eine Referenz, die zur Identifizierung einer Entität verwendet wird, kann jedoch nicht auf solche Weise ersetzt werden. Entweder ist die Entität selbst etwas, das nicht kopiert werden kann (z. B. wenn es eine Verbindung zu etwas in der realen Welt darstellt) oder das Entität kann einkapseln Die Reihe von Referenzen, die darauf existieren. Eine wichtige Sache zu beachten ist, dass Objekte sich als Werte verhalten, wenn sie sich entweder nicht ändern oder nur eine Referenz auf sie gibt, und sie verhalten sich wie Entitäten, wenn mehrere Referenzen vorhanden sind.

Durch die Unterscheidung der Unterscheidung zwischen Werten und Entitäten ist es für die Sammlungstypen schwierig, zu wissen, ob sie ihren Inhalt als Werte oder Entitäten betrachten sollten. Dies schränkt wiederum die Fähigkeit von Sammlungen ein, Dinge wie zu implementieren wie equals oder clone in nützlicher Weise. Sprachen, die eine stärkere Art/Entity -Unterscheidung machen, können Sammlungen automatisch tun als Sprachen, die dies nicht tun, aber die Unterscheidungen führen zu einer gewissen Komplexität, die Sprachdesigner möglicherweise für die Vorteile gerechtfertigt sind oder nicht.