Eine Frage an die OOP-Experten. - Seite 3
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Kreatur.
Flora/Fauna
Unterarten
Arten
Familie
usw.
Ist es das, was Sie wollen?
Nun, es ist eine einfache Vererbung von der Basisentität "Entity".
Aber man kann noch tiefer gehen - es gibt einzellige und mehrzellige Lebewesen, und das ist auch schon alles. Aber es gibt auch nicht-lebendige. Alles hängt von Aufgaben ab, für die man Eigenschaften eines Basisobjekts finden und von ihnen erben muss.
Wenn du wirklich verrückt bist, kannst du zu den Atomen gelangen und sie auf der Suche nach einem grundlegenden Ausgangsobjekt in Teile zerlegen (sei vorsichtig - eine Spaltungsreaktion kann zu einer Kettenreaktion werden, und du wirst die halbe Welt zerstören :))
Richtig. Auf den ersten Blick ist das Konzept der OOP ideal für den Aufbau einer Hierarchie. Aber wie arbeitet man mit einer durch OOP aufgebauten Hierarchie? Es ist ein Meer von Syntax und Komplexität der Übergänge zwischen den Links wegen der Zugriffsrechte auf die Klassen und ihre Inhalte. Hier beginnt der Overhead, der sich aus der Einteilung in Klassen ergibt. Einerseits erlaubt OOP den Aufbau einer Hierarchie, andererseits macht es die Arbeit mit ihr extrem schwierig.
Nun, nein. OOP ermöglicht einen sehr einfachen Zugriff auf jedes Mitglied der Hierarchie an jeder beliebigen Stelle.
Beginnen Sie damit, Ihr Basisobjekt mit den minimal erforderlichen Eigenschaften zu finden.
Der Rest der Objekte erbt von ihm. Um das Rad nicht neu zu erfinden, sollte Ihr Basisobjekt die Klasse CObject aus der Standardbibliothek erben. So können Sie Ihre eigene Hierarchie von Objekten erstellen, ohne die Listen neu erfinden zu müssen.
CObject --> CBaseObject --> Ihre Hierarchie.
In CBaseObject müssen Sie eine virtuelle Methode haben, die dieses Objekt zurückgibt. Dann wird jeder der Nachkommen über diese Methode verfügen, und sie wird genau das Nachkommenobjekt zurückgeben. Die Basisklasse von CObject hat bereits eine Methode -Type(). Wenn Sie die gleiche virtuelle Methode von CBaseObject haben und sie den Typ des Objekts zurückgibt, wissen Sie, auf welches Objekt Sie zugegriffen haben.
Es ist wie ein Grundgerüst für alle Ihre Objekte. Und sie sollten alle in eigenen Listen gespeichert werden - jede Liste wird nur Objekte einer Art enthalten - Fische, Tiere, Menschen, Götter usw.
Das heißt, Sie brauchen eine Liste für jeden Untertyp. Und es muss eine Liste geben, die die folgenden Listen in der Hierarchie enthält. Jede dieser Listen muss auch - wieder - Listen haben, die in der Hierarchie die nächsten sind. Und so weiter.
D.h., Sie benötigen auch ein Basislistenobjekt, in das Sie die benötigten Listen einfügen werden. Und diese Basisliste muss eine Type()-Methode haben, und es muss eine Methode geben, die es erlaubt, jedes darin gespeicherte Objekt anhand seines Indexes zurückzugeben. Wenn Sie dies tun, haben Sie automatisch eine Methode in jeder der Listen, die das gewünschte Objekt zurückgibt.
Im Allgemeinen müssen Sie zuerst Ihr Basisobjekt und dann Ihr Listenobjekt durchdenken. Sie brauchen auch keine Objektlisten zu erstellen, da sie bereits existieren.
Und dann ist es eine Frage der Technik. Und Sie müssen nur die Art des gesuchten Objekts kennen. In der Hierarchie gibt es viele Typen, und jeder von ihnen ist Ihnen bekannt, und Sie können ihn anfordern und erhalten.
Wie es mir schien, hat das in diesem Fall nichts mit OOP zu tun.
In Peters Fall werden alle Objekte im Array nach einem Schlüssel gesucht, und es macht keinen Unterschied, ob Sie Klassen, Arrays oder überhaupt eine Reihe von deklarierten Objekten verwenden.
OOP erlaubt es, eine Liste von Objekten zu haben, von denen jedes, sagen wir, die Methode GetColor() hat - und der Benutzer geht durch alle Objekte auf der Suche nach der richtigen Farbe. Aber wenn wir ohne OOP ein Array von identischen Strukturen haben, die der Benutzer kennen muss, um die Farbe von dort zu holen, wo sie benötigt wird, muss der Benutzer mit OOP nicht genau wissen, wie und wo die Farbe gespeichert ist - die GetColor()-Methode des Objekts weiß, wo die Farbe zu holen ist.
Das heißt, für OOP - der Benutzer muss nicht wissen, wie und wo die Farbe des Objekts gespeichert ist. Wenn wir also plötzlich ein "Objekt für Blinde" hinzufügen müssen, bei dem die Farbe durch Braille-Punkte kodiert wird, können wir dieses Objekt einfach zu unserer Liste hinzufügen und nur seine GetColor()-Methode ändern, die den Farbcode von den Punkten in Braille-Schrift erhält und ihn in regulärer Form zurückgibt. Für die Nutzer unserer Liste ändert sich nichts.
Wenn wir nur ein Array haben, können wir dort keine "Braille-Punkte" einfügen. Wir haben dort kein solches Feld.
Der Vorteil von OOP ist sehr gut zu sehen, wenn wir von CObject erben, dann ein Array von Objekten CArrayObj erstellen und dann, indem wir nur eine Vergleichsfunktion schreiben - wir bekommen sofort die Möglichkeit, schnell zu sortieren und binär zu suchen.
Grob gesagt, für mein obiges Beispiel mit Farbe - für OOP - schreiben wir eine Vergleichsfunktion, die die Farbe durch GetColor() erhält, und wir können unsere Objekte nach Farbe sortieren, auch ohne zu wissen, dass wir die Hälfte der Objekte mit echter Farbe und die Hälfte mit "Braille-Punkten" haben.Und wenn wir ein Objekt mit einer neuen Farbkodierung hinzufügen wollen - auch hier müssen wir nur die Funktion GetColor() schreiben, die seine Farbdarstellung auf den Standard bringt - und dann werden die bereits geschriebenenSortier- undSuchalgorithmen dieses neue Objekt ohne Probleme akzeptieren.
Das heißt, OOP hat es uns ermöglicht, einen Sortier- und Abrufalgorithmus für noch nicht geschriebene Objekte zu haben, bevor wir überhaupt entschieden haben, wie sie genau dargestellt und gespeichert werden sollen.
Die Vorteile von OOP sind wirklich klar, wenn wir von CObject erben, dann ein Array von Objekten CArrayObj erstellen und dann nur eine Vergleichsfunktion schreiben, erhalten wir schnelle Sortierung und binäre Suche.
Es ist ein Meer von Syntax und Schwierigkeiten mit Übergängen zwischen Links aufgrund von Zugriffsrechten auf Klassen und deren Inhalte. Hier beginnt der Overhead, der sich aus der Einteilung in Klassen ergibt. OOP ermöglicht es einerseits, eine Hierarchie aufzubauen, andererseits macht es die Arbeit damit extrem schwierig.
Modifikatoren für Zugriffsrechte ermöglichen die Erkennung von Fehlern zur Kompilierungszeit
Im Allgemeinen ist all dies nicht kompliziert die Arbeit mit Klassen, nicht verwenden, schreiben Sie alles in der Öffentlichkeit: und dann wird es einfacher sein, mit ihnen zu arbeiten.
SZZY: Eine Menge netter Phrasen über OOP, Kapselung und Vererbung... Das ist alles gut, aber der Hauptvorteil von OOP gegenüber anderen Programmierstilen ist die Speicherung aller Daten (Klassenfelder) und Funktionen für die Arbeit mit diesen Daten (Klassenmethoden) an einem Ort (Klasse) - in der Fachsprache heißt das Verkapselung. Des Weiteren hängt die Verwendung von OOP von der Aufgabe ab, wenn die Aufgabe es erlaubt, Klassen zu skalieren, wird eine Hierarchie benötigt und es wird Basisklassen und deren Nachkommen geben - ob man diese verwendet, hängt von einem selbst ab
Ich muss zugeben, dass "Objekt" im OOP-Konzept in einem breiteren Kontext als in meinem "Kernel" dargestellt wird. Das ist aber nicht verwunderlich, da ich mich bisher nur mit Grafiken beschäftigt habe und OOP für eine breite Palette von Aufgaben verwendet wird. Mein "Menü" von Objekten ist eher spärlich und außer "Label", "Element", "Fenster" gibt es wahrscheinlich nicht viel mehr... Für grafische Schnittstellen brauche ich jedoch nichts mehr.
Nun stellt sich jedoch die Frage nach einer Erweiterung des Begriffs "Objekt" und dem Aufbau einer Hierarchie. Ein einfacher zweidimensionaler Kernel kann nicht die gesamte Vielfalt der Objekte der Wissensbasis aufnehmen. Daher sollte entweder ein anderer Kernel für verschiedene Objekte geschaffen oder das Konzept der OOP verfolgt werden.
Im Grunde genommen ist dies eine rein technische Frage. Was ist effizienter, was ist schneller, was ist besser lesbar usw...
In der Tat können Sie einfach alle Objekte in einem Array als Liste von Eigenschaften aufbewahren, unter denen sich Zeiger auf andere Arrays mit anderen Objekten usw. befinden. OderSie können explizitOOP verwenden. Die Objektorientierung ist in beiden Ansätzen unveränderlich vorhanden, nur die Methoden der Implementierung sind unterschiedlich. Der gleiche Speicher, die gleichen Zeiger, die gleichen Objekte, die gleiche Klassifizierung. Nur die Form des Codes ist anders...
Ich wollte Peter davon erzählen, wenn er das Konzept der Datenspeicherung, das ihm vorgeschlagen wurde, verstanden hat.
Ich werde versuchen, dieses Konzept der Speicherung und Verarbeitung von Daten zu verstehen.
Okay. (gluckst) Wir können uns persönlich über das Thema unterhalten. Oder über Skype, wie Sie möchten. Es ist nur so, dass die Einzelheiten nicht zum Thema dieses Threads gehören - hier geht es, so wie ich es verstehe, nur um allgemeine Fragen.