OOP vs. prozedurale Programmierung - Seite 26
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
Es gibt nicht viel, worüber man nachdenken muss.
OOP ist ein Mechanismus, der es uns ermöglicht, viele Prüfungen und Genehmigungen an den Compiler weiterzugeben. Allerdings müssen wir einige zusätzliche Anstrengungen unternehmen, um sie zu nutzen.
Aber wenn wir all diese Prüfungen und Anpassungen nicht brauchen, macht es keinen Sinn, OOP zu verwenden.
Ich würde zum Beispiel vorsichtig sein, wenn ich mit einem mehrdimensionalen Array eines grafischen Kerns arbeiten würde - weil es zu viele unnötige Einheiten enthält, die im Moment nicht benötigt werden. Sie sind ablenkend und provozieren schwer zu berechnende Fehler. Ich würde sie durch eine Reihe von Objekten ersetzen, auf die ich mit einfachen, kompakten Schnittstellen zugreifen würde. Indem ich eine Schnittstelle bekomme - ich muss mir nichts merken - schränkt mich die Schnittstelle selbst ein und verhindert, dass ich beispielsweise auf das falsche Feld oder Objekt zugreife. Im Falle eines grafischen Kernel-Arrays ist eine solche Handhabung durchaus möglich.
Das heißt, wenn ein Block eine Schnittstelle erhält, "schneidet" der Compiler selbst alle unnötigen Einheiten ab und verhindert, dass der Benutzer einen Fehler macht. Bei einem grafischen Kernel-Array hat der Benutzer jedoch eine Menge unnötiger Informationen, bei denen er leicht einen Fehler machen kann.
Ich habe die Erfahrung gemacht, dass ich viel besser dran bin, wenn der Compiler selbst darauf achtet, was ich im aktuellen Block nicht tun sollte. Und mit einem grafischen Kernel-Array - das muss ich mir merken. Das Minus in meinem System ist eine Erweiterung des Plus. Wenn ich plötzlich etwas in einem Block brauche, das über die aktuelle Aufgabe hinausgeht, ist das mit einem grafischen Kernel-Array ganz einfach - man nimmt einfach die benötigten Daten und arbeitet damit. Bei OOP-Schnittstellen müssen Sie jedoch entweder die erforderlichen Daten in einer zusätzlichen Schnittstelle anfordern oder (was viel unangenehmer ist) die vorhandene Schnittstelle ändern.
Es gibt nicht viel, worüber man nachdenken muss.
OOP ist ein Mechanismus, der es uns ermöglicht, viele Prüfungen und Genehmigungen an den Compiler weiterzugeben. Allerdings müssen wir einige zusätzliche Anstrengungen unternehmen, um sie zu nutzen.
Aber wenn wir all diese Prüfungen und Anpassungen nicht brauchen, macht OOP keinen Sinn.
Aber warum sollte man es so sehr vereinfachen? Und wie steht es um die Klarheit und Lesbarkeit? Und die Einfachheit der Fehlererkennung und -korrektur? Und die Tragbarkeit? Und einfache Aufrüstung? usw., usw. ....
Nun, dann sollte das Thema anders klingen. Etwas wie: "Ein neues Toolkit für die Programmierung" oder "Ein neues Programmierparadigma"...
Wenn es wahr ist, dass du etwas Cooleres als OOP geschaffen hast, wirst du dann dein Autogramm geben, wenn du berühmt wirst?
Kein Problem! Für ein Autogramm für Ihre Freunde werden keine Kosten gescheut. ))))
Sie scherzen, aber in meiner Vorstellung habe ich eine solche Einstellung zu diesem Ansatz, dass es ein echter Flop ist. Es scheint, dass ich mit der Zeit in der Lage sein werde, den Mechanismus der Selbstverbesserung des Systems zu starten. Wenn ich einen logischen Kernel erstelle und ihn nach dem Zufallsprinzip verschiedene Mechanismen erzeugen lasse. Dann müssen Sie nur noch auswählen und die richtigen auswählen. Dann schleifen Sie sie ein wenig aus... Dank des Kernels können unglaubliche Dinge getan werden.
Warum die Dinge so sehr vereinfachen? Und die Klarheit und Lesbarkeit? Und wie einfach ist die Fehlererkennung und -korrektur? Wie sieht es mit der Übertragbarkeit aus? Und einfache Aufrüstung? usw., usw. ....
schönes Werbebanner :-) "Kaufen Sie unsere Elefanten."
alle diese Thesen sind gleichermaßen auf OOP und Nicht-OOP und FP und überall sonst anwendbar
Es gibt nicht viel, worüber man nachdenken muss.
OOP ist ein Mechanismus, der es uns ermöglicht, viele Prüfungen und Genehmigungen an den Compiler weiterzugeben. Allerdings müssen wir einige zusätzliche Anstrengungen unternehmen, um sie zu nutzen.
Aber wenn wir all diese Prüfungen und Anpassungen nicht brauchen, macht es keinen Sinn, OOP zu verwenden.
Ich würde zum Beispiel vorsichtig sein, wenn ich mit einem mehrdimensionalen Array eines grafischen Kerns arbeiten würde - weil es zu viele unnötige Einheiten enthält, die im Moment nicht benötigt werden. Sie sind ablenkend und provozieren schwer zu berechnende Fehler. Ich würde sie durch eine Reihe von Objekten ersetzen, auf die ich mit einfachen, kompakten Schnittstellen zugreifen würde. Indem ich eine Schnittstelle bekomme - ich muss mir nichts merken - schränkt mich die Schnittstelle selbst ein und verhindert, dass ich beispielsweise auf das falsche Feld oder Objekt zugreife. Im Falle eines grafischen Kernel-Arrays ist eine solche Handhabung durchaus möglich.
Das heißt, wenn ein Block eine Schnittstelle erhält, "schneidet" der Compiler selbst alle unnötigen Einheiten ab und verhindert, dass der Benutzer einen Fehler macht. Bei einem grafischen Kernel-Array hat der Benutzer jedoch eine Menge unnötiger Informationen, bei denen er leicht einen Fehler machen kann.
Meiner Erfahrung nach bin ich viel besser dran, wenn der Compiler selbst auf Dinge achtet, die ich im aktuellen Block nicht verändern sollte. Und mit einem grafischen Kernel-Array - das muss ich mir merken. Das Minus in meinem System ist eine Erweiterung des Plus. Wenn ich plötzlich etwas in einem Block brauche, das über die aktuelle Aufgabe hinausgeht, ist das mit einem grafischen Kernel-Array ganz einfach - man nimmt einfach die benötigten Daten und arbeitet damit. Bei OOP-Schnittstellen müssen Sie jedoch entweder die erforderlichen Daten in einer zusätzlichen Schnittstelle anfordern oder (was viel unangenehmer ist) die vorhandene Schnittstelle ändern.
Sie irren sich, wenn Sie glauben, dass der Kernel etwas Unnötiges enthält. Und es ist sehr einfach, sich an ihre Wesenheiten zu erinnern, weil sie durch Definitionen in menschliche Worte gekleidet sind. Dort wird alles gesammelt, aber dieser Inhalt hat eine klare und unveränderliche Ordnung. Die Eigenschaften von Objekten, Fenstern und Elementen sind an jeder Stelle des Programms direkt zugänglich. Und welche Wunder man mit dem Kernel in Schleifen vollbringen kann...
Sie liegen völlig falsch, wenn Sie glauben, dass der Kernel etwas Zusätzliches enthält. Und es ist sehr einfach, sich an ihre Wesenheiten zu erinnern, weil sie durch Definitionen in menschliche Worte gekleidet sind. Dort wird alles gesammelt, aber dieser Inhalt hat eine klare und unveränderliche Ordnung. Die Eigenschaften von Objekten, Fenstern und Elementen sind an jeder Stelle des Programms direkt zugänglich. Und welche Wunder man dank des Kernels in Schleifen vollbringen kann...
Ich habe nicht gesagt, dass "der Kernel überflüssig ist", sondern dass er "derzeit unnötig ist". Wenn ich mit einer Diagrammlinie arbeite, sollte ich nicht auf die Fenstereigenschaften zugreifen können.
Allein die Tatsache, dass alle diese Eigenschaften überall im Programm direkt zugänglich sind, ist der größte Nachteil Ihres Ansatzes. An jeder Stelle des Programms sollten nur die Elemente zugänglich sein, die zu diesem Zeitpunkt benötigt werden. Alles andere sollte nicht verfügbar sein. Auf diese Weise können Sie automatisch viele Fehler vermeiden.
All die "Wunder, die man dank der Zugänglichkeit des gesamten Kerns tun kann", sind meiner Meinung nach eine potenzielle Quelle für schwer zu findende Fehler und Probleme beim Verständnis des Codes. Man sollte versuchen, all diese Tricks zu vermeiden.
Dieser Ansatz erinnert mich an sehr dumme Aufgaben, bei denen Zeiger, Inkremente und Verweise in einer Zeile in einem Durcheinander geschrieben werden, das vielleicht sprachlich korrekt, aber überhaupt nicht lesbar ist. Ich habe oben meine eigene Funktion zitiert, die auch völlig verrückt aussieht, aber ich dachte, dass Kompaktheit in diesem Fall wichtiger ist.
Warum sollte man es so sehr vereinfachen? Und die Übersichtlichkeit und Lesbarkeit? Und wie leicht lassen sich Fehler erkennen und korrigieren? Und die Tragbarkeit? Und einfache Aufrüstung? usw., usw. ....
Fantastisch!
1. Vor dem Oop haben wir alle alles aus maßgefertigten Komponenten mit außergewöhnlich komplexen Werkzeugen gebaut.
2. Vor OOP waren Programme ein außergewöhnlich gut gemischtes Kompott
3. Vor OOP hatten wir NICHTS über die Lokalisierung von Daten und Code gehört, was unsere Wartung extrem mühsam machte.
4. Die Datensicherung zwischen verschiedenen Teilen desselben Programms war ein Alptraum!
5. Vor OOP hat niemand jemals Systeme erweitert.
Dies ist ein völliger Fehlschlag.
Ich sitze da und denke, dass vielleicht genau dieses OOP aus mir herausgewachsen ist, weil ich das alles schon in den späten 70er Jahren angewandt habe und viele andere Dinge, die mit der Programmierkultur zu tun haben.
Ich habe nicht gesagt, dass es etwas Unnötiges im Kernel gibt, sondern dass es im Moment unnötig ist. Wenn ich mit einer Diagrammlinie arbeite, sollte ich nicht auf die Fenstereigenschaften zugreifen können.
Allein die Tatsache, dass alle diese Eigenschaften überall im Programm direkt zugänglich sind, ist der größte Nachteil Ihres Ansatzes. An jeder Stelle des Programms sollten nur die Elemente zugänglich sein, die zu diesem Zeitpunkt benötigt werden. Alles andere sollte nicht verfügbar sein. Auf diese Weise können Sie automatisch viele Fehler vermeiden.
All die "Wunder, die man dank der Zugänglichkeit des gesamten Kerns tun kann", sind meiner Meinung nach eine potenzielle Quelle für schwer zu findende Fehler und Probleme beim Verständnis des Codes. Man sollte versuchen, all diese Tricks zu vermeiden.
Dieser Ansatz erinnert mich an die dümmsten Aufgaben, bei denen Zeiger, Inkremente und Verweise in einer Zeile in einem Durcheinander geschrieben werden, das zwar sprachlich korrekt, aber absolut unlesbar ist. Ich habe oben meine eigene Funktion zitiert, die auch völlig verrückt aussieht, aber ich dachte, dass Kompaktheit in diesem Fall wichtiger ist.
Ihre Überlegungen zum Kernel basieren auf momentanen theoretischen Vorstellungen, die auf Ihrer Erfahrung beruhen und nichts mit der Technologie zu tun haben, über die Sie sprechen. Daher einige Probleme mit dem Zugang, dem Erinnern an Entitäten...
Ich spreche aus praktischer Erfahrung mit dieser Technologie, und ich sage, dass es keine derartigen Probleme mit dem Zugang oder der Beschränkung des Zugangs gibt. Ehrlich gesagt, weiß ich gar nicht, von welchen Zugangsproblemen Sie sprechen. Es gibt keine derartigen Probleme, und es hat auch nie welche gegeben.
Bitte erläutern Sie, auf welche Zugangsprobleme Sie sich beziehen.
Wie kommen Sie darauf, dass der Zugang eingeschränkt werden muss, wenn dies zu Fehlern führen würde? Das ist etwas Neues für mich.
Kann der direkte Zugriff auf ein globales Array in einem Prozedurcode selbst schwer zu findende Fehler verursachen?
Sie sprechen über den Kernel auf der Grundlage Ihrer unmittelbaren theoretischen Vorstellungen, die auf Ihrer Erfahrung beruhen und nichts mit der Technologie zu tun haben, über die Sie sprechen. Daher einige Probleme mit dem Zugang, dem Erinnern an Entitäten...
Ich spreche aus praktischer Erfahrung mit dieser Technologie, und ich sage, dass es keine derartigen Probleme mit dem Zugang oder der Begrenzung des Zugangs gibt. Ehrlich gesagt, weiß ich gar nicht, von welchen Zugangsproblemen Sie sprechen. Solche Schwierigkeiten gibt es nicht und hat es nie gegeben.
Was meinen Sie mit "kein Problem", wenn Sie sagen "alles ist von überall aus zugänglich"?
Das ist das Hauptproblem! Es sollte nicht zugänglich sein!
Es geht darum, die Aufgabe der Zugriffskontrolle auf den Compiler zu verlagern. Alles ist offen, und der Programmierer kontrolliert den Zugang.
Es gab keine Komplikationen, weil Sie sich an alles erinnern. Irgendwann werden Sie feststellen, dass Ihr Gedächtnis versagt, und dann werden Sie die Fähigkeit des Compilers zu schätzen wissen, den Zugriff zu kontrollieren. Das weiß ich nicht mehr. Und ich vermute, dass die meisten Menschen auch regelmäßig vergessen, wie etwas funktioniert, das vor Monaten geschrieben wurde. Unter diesen Umständen ist die Abgrenzung des Zugangs ein Segen.
Angenommen, Sie befinden sich innerhalb des Blocks, der für die Erteilung von Aufträgen zuständig ist - Sie haben nur die Möglichkeit, Aufträge zu erteilen. Und Sie haben nicht die Möglichkeit, ein Diagramm zu zeichnen. Wenn Sie sich in einem Block befinden, der für das Zeichnen eines Diagramms zuständig ist, können Sie von dort aus keinen Auftrag erteilen. Dies vereinfacht die Arbeit erheblich. Und wenn Sie beim Zeichnen eines Diagramms plötzlich die Aufforderung sehen, einen Auftrag zu erteilen, werden Sie lange überlegen müssen, warum Sie das getan haben. Es wäre schön, wenn es einen ausführlichen Kommentar gäbe, der erklärt, warum diese Entscheidung getroffen wurde... Es ist jedoch besser, wenn die Aufträge in einem einzigen, speziellen Block erteilt werden.
Wie kann es "kein Problem" geben, wenn Sie sagen, "alles ist von überall aus zugänglich"?
Das ist das Hauptproblem! Sie darf nicht zugänglich sein!
Es geht nur darum, die Aufgabe der Zugriffskontrolle auf den Compiler zu verlagern. Alles ist offen, und der Programmierer kontrolliert den Zugang.
Es gab keine Komplikationen, weil Sie sich an alles erinnern. Irgendwann werden Sie feststellen, dass Ihr Gedächtnis versagt, und dann werden Sie die Fähigkeit des Compilers zu schätzen wissen, den Zugriff zu kontrollieren. Das weiß ich nicht mehr. Und ich vermute, dass die meisten Menschen auch regelmäßig vergessen, wie etwas funktioniert, das vor Monaten geschrieben wurde. Unter diesen Umständen ist die Zugangskontrolle ein Segen.
Angenommen, Sie befinden sich innerhalb des Blocks, der für die Erteilung von Aufträgen zuständig ist - Sie haben nur die Möglichkeit, Aufträge zu erteilen. Und Sie haben nicht die Möglichkeit, ein Diagramm zu zeichnen. Wenn Sie sich in einem Block befinden, der für das Zeichnen eines Diagramms zuständig ist, können Sie von dort aus keinen Auftrag erteilen. Dies vereinfacht die Arbeit erheblich. Und wenn Sie beim Zeichnen eines Diagramms plötzlich die Aufforderung sehen, einen Auftrag zu erteilen, werden Sie lange überlegen müssen, warum Sie das getan haben. Es wäre schön, wenn es einen ausführlichen Kommentar gäbe, der erklärt, warum diese Entscheidung getroffen wurde... Es ist jedoch besser, wenn die Aufträge in einem einzigen, speziellen Block erteilt werden.