Ein Crowdsourced-Projekt auf Canvas durchführen - Seite 24
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
Wenn zwei Programmierer mit der gleichen Erfahrung und Intelligenz miteinander konkurrieren und ähnlichgroße Projekte entwickeln. Im ersten Fall werden jedoch nur Funktionen verwendet, während im zweiten Fall Funktionen und Klassen verwendet werden. Der Sieg wird auf jeden Fall der zweite sein. Aber, ich wiederhole, wenn es sich um ein umfangreiches Projekt handelt, wird es mit letzterem schneller gehen, weil es weniger Fehler und mehr Ordnung gibt. Und das zweite Produkt wird besser lesbar, wartbar und leichter zu aktualisieren und zu ergänzen sein. Das ist nicht einmal meine Meinung, sondern nur eine Feststellung von Tatsachen. Es ist einfacher, ein Loch mit einer Schaufel zu graben als mit einer Kelle. Wenn Sie Ihren Mechanismus nicht nur auf Funktionen, sondern auch auf Klassen anwenden würden, wäre er effizienter. Dies ist meine Meinung.
Beginnen wir mit der Frage nach der Notwendigkeit von Klassen bei der Implementierung großer Mechanismen. Eine Klasse ist eine Hülle für eine Reihe von Funktionen, und ein "großer Mechanismus" ist ein Codeblock, der eine Reihe von Aufgaben implementiert. In meiner Implementierung ist ein "großer Mechanismus" fast immer eine sehr große Funktion und eine Reihe kleinerer Funktionen, die ihr dienen. Der so genannte "Motor". Wenn man sie mit Servierfunktionen in eine Klasse packt, ändert sich nichts, und wenn man sie in verschiedene Klassen packt, wird der Zugriff zwischen ihnen komplizierter und die Effizienz des Mechanismus geringer.
Wenn die Größe des Mechanismus zunimmt, müssen Sie seinen Code optimieren oder die Funktionalität in Dateien aufteilen. Reicht das nicht aus? Außerdem führt die regelmäßige Optimierung des Codes in einem Block zu Wundern der Effizienz. Es wird ständig komprimiert und benötigt immer mehr Funktionen, um umgesetzt zu werden. Das heißt, die Anzahl der Funktionen nimmt im Gegenteil ab. Sie sind in einem Block zusammengefasst, dessen Code ständig verbessert wird. Dies ist ein direkter Weg zur Effizienz .
Wenn wir wichtige Variablen global machen, werden sie überall im Mechanismus sichtbar sein und es wird einfach sein, mit ihnen zu arbeiten, und wenn wir Bereiche für sie definieren, wird das vom Standpunkt der Effizienz des Mechanismus eine überflüssige Aufgabe sein. Auch hier wird der Zugang erschwert. Erstellen von Klassenobjekten, und so weiter... Die Tendenz, den Mechanismus in eine große Anzahl von Funktionen zu unterteilen, ruiniert nicht nur die Effizienz, sondern auch die Universalität der Codeblöcke. Es stellt sich heraus, dass jede konkrete Aufgabe eine eigene Funktion benötigt, und die Universalität von Codeblöcken wird einfach nicht verbessert. Auch die Anzahl der Aufrufe und der übergebenen Parameter nimmt zu. Dies trägt nicht zur Effizienz des Mechanismus bei, aber diese Tendenz wird durch OOP sogar gefördert.
OOP ist effizienter, wenn ein Projekt von einem Team von Programmierern bearbeitet wird. In diesem Fall können Sie nicht auf sie verzichten. Obwohl, wenn man darüber nachdenkt, kann man auch hier einen Weg finden, ohne sie auszukommen...
Aber das sind natürlich alles nur Worte. In der Praxis würde ich schnell beweisen, wovon ich spreche.
Nikolai Semko:
Und, Peter, ich habe einen kurzen Blick auf deinen Code geworfen und festgestellt, dass du Canvas in vollem Umfang verwendest (nicht die CCanvas-Klasse, aber wen interessiert das schon). Warum dann all diese Fragen zur Leinwand und warum ich versuche, all diese Dinge hier zu erklären? :)).
)))), ich bin etwas überrascht über Ihre Erklärungen zu den Zeichenprinzipien von Kanvas. Ich habe Ihnen bereits gesagt und gezeigt, dass alles auf meinen Kanvas gezeichnet ist.)) (Also fast alles. :))
Ich habe dieses Thema gestartet, weil ich nicht verstehen kann, warum bisher noch niemand den gleichen Button wie meinen gezeichnet hat. Schließlich ist es, wie Sie sagen, ganz einfach.
))), ich war auch ein wenig überrascht von Ihrer Erklärung der Prinzipien des Zeichnens auf Leinwand, denn ich habe Ihnen schon einmal gesagt und gezeigt, dass alles gezeichnet wird.)) (Also fast alles. :))
Ich habe dieses Thema gestartet, weil ich nicht verstehen kann , warum bisher noch niemand den gleichen Button wie meinen gezeichnet hat. Schließlich ist es, wie Sie sagen, ganz einfach.
Wenn Sie es nicht gesehen haben, heißt das nicht, dass niemand außer Ihnen es nicht kann. Es ist nur so unbedeutend, dass du es nicht einmal posten musst - ein zu unbedeutendes Ereignis - nur einen Button zu erstellen - um seinen Code zu posten, nicht weil du der Beste bist ;)
Sie alle konkurrieren - und das zu Recht, Anatoly - mit Windmühlen.
Wenn Sie es nicht gesehen haben, heißt das nicht, dass niemand außer Ihnen in der Lage ist, es zu tun. Es ist nur so unbedeutend, dass es keinen Grund gibt, es zu posten - ein zu unbedeutendes Ereignis - nur das Erstellen eines Buttons - um seinen Code zu posten, nicht weil du der Beste bist ;)
Sie alle konkurrieren - und das zu Recht, Anatoly - mit Windmühlen.
Beruhige dich, Artem. Ich habe schon gemerkt, dass du mich nicht magst. Offensichtlich tun das auch viele andere in dieser Quelle. Vielleicht ist es gerechtfertigt, aber es ist zu viel, wenn man bei der Erörterung technischer Fragen aus heiterem Himmel seine Persönlichkeit ändert.
Ich bin ruhig, wie kommst du darauf?
Eine Person mögen oder nicht mögen - das ist kein technisches Forum zum Diskutieren. Sie sind für mich neutral - mehr nicht. Genauso viel wie für den Rest von uns, wie mir scheint.
Aber damit Sie nicht im Stil von "ah-ah-ah..., es ist dieser Don Quijote..., ich erinnere mich, ich erinnere mich..." erwähnt werden, müssen Sie zumindest etwas Nützliches tun.
Sie können tun oder lassen, was Sie wollen - das ist Ihr gutes Recht und wird von niemandem bestritten. Niemand braucht hier Ihr Wort - Sie sollten es sich selbst geben ;)
Die Atmosphäre ist sehr freundlich - die Leute erzählen dir, wie schön es ist , OOP in manchen Situationen zu verwenden, ein Mann kreuzt vor dir auf, versucht dir bei etwas zu helfen, programmiert für dich, um es dir zu zeigen, damit du es besser verstehst. Aber aus Ihren eigenen Worten geht hervor, dass Sie es gar nicht nötig haben - Sie wissen einfach nicht, mit wem Sie sonst noch konkurrieren sollen, und versuchen, andere "schwach" herauszufordern.
Und was mir auch scheint - du bist nicht, weil du dich entschieden hast, nicht zu schreiben und nicht OOP zu studieren, dass du alles abgewogen und verstanden hast, dass du mit prozeduraler Programmierung viel besseren und optimierten Code schreibst (so wie du es hier allen präsentiert hast), sondern einfach, weil du nichts davon verstehst und eine Ausrede erfunden hast, die du allen verkündet hast und sie mit Worten und der Aufforderung "glaube nur dem, der mich schlägt" unterstützt.
Erinnern Sie sich an den Witz über "Elusive Joe"?
...
Erinnern Sie sich an den Witz über "Elusive Joe"?
Dem stimme ich voll und ganz zu.
Der schwer fassbare Lyriker/Philosoph... :-) der gleiche Mist wie "Joe", nur in der "anderen Hand"... :-)
Beginnen wir mit der Frage nach der Notwendigkeit von Klassen bei der Implementierung großer Mechanismen. Eine Klasse ist eine Hülle für eine Reihe von Funktionen, und ein "großer Mechanismus" ist ein Codeblock, der eine Reihe von Aufgaben implementiert. In meiner Umsetzung ist eine "Große Maschine" fast immer eine sehr große Funktion und eine Reihe kleinerer Funktionen, die ihr dienen. Der so genannte "Motor". Wenn man sie mit Servierfunktionen in eine Klasse packt, ändert sich nichts, und wenn man sie in verschiedene Klassen packt, wird der Zugriff zwischen ihnen komplizierter und die Effizienz des Mechanismus geringer.
Wenn die Größe des Mechanismus zunimmt, müssen Sie seinen Code optimieren oder die Funktionalität in Dateien aufteilen. Reicht das nicht aus? Außerdem führt die regelmäßige Optimierung des Codes in einem Block zu Wundern der Effizienz. Es wird ständig komprimiert und benötigt immer mehr Funktionen, um umgesetzt zu werden. Das heißt, die Anzahl der Funktionen nimmt im Gegenteil ab. Sie sind in einem Block zusammengefasst, dessen Code ständig verbessert wird. Dies ist ein direkter Weg zur Effizienz .
Wenn wir wichtige Variablen global machen, werden sie überall im Mechanismus sichtbar sein und es wird einfach sein, mit ihnen zu arbeiten, und wenn wir Bereiche für sie definieren, wird das vom Standpunkt der Effizienz des Mechanismus eine überflüssige Aufgabe sein. Auch hier wird der Zugang erschwert. Erstellen von Klassenobjekten, und so weiter... Die Tendenz, den Mechanismus in eine große Anzahl von Funktionen zu unterteilen, ruiniert nicht nur die Effizienz, sondern auch die Universalität der Codeblöcke. Es stellt sich heraus, dass jede konkrete Aufgabe eine eigene Funktion benötigt, und die Universalität von Codeblöcken wird einfach nicht verbessert. Auch die Anzahl der Aufrufe und der übergebenen Parameter nimmt zu. Dies trägt nicht zur Effizienz des Mechanismus bei, aber diese Tendenz wird durch OOP sogar gefördert.
OOP ist effizienter, wenn ein Projekt von einem Team von Programmierern bearbeitet wird. In diesem Fall können Sie nicht auf sie verzichten. Obwohl, wenn man darüber nachdenkt, kann man auch hier einen Weg finden, es zu vermeiden...
Aber das sind natürlich alles nur Worte. In der Praxis würde ich schnell beweisen, wovon ich spreche.
Peter, es ist nur so, dass ich früher nur mit Funktionen programmiert habe und fast genauso argumentiert habe wie du jetzt, und dann habe ich fast zwangsweise (denn die Macht der Gewohnheit ist unglaublich) angefangen, mit Klassen zu programmieren. Jetzt kann ich die beiden Zustände vergleichen, während Sie, der Sie nicht versucht haben, Klassen anzuwenden, dies nicht können. Nichts für ungut. Das erinnert mich nur an eine andere Situation. Ich bin schon seit vielen Jahren Vegetarier. Und mit beneidenswerter Regelmäßigkeit gibt es Leute, die noch nie Vegetarier waren und versuchen, mir etwas über Proteine, essenzielle Aminosäuren usw. einzureden. Ich sage ihnen: Wir sind nicht unter gleichen Bedingungen, ich war Fleischesser und jetzt bin ich Vegetarier, also kann ich diese beiden Bedingungen in Bezug auf die Praxis vergleichen. Sie sind es nicht und Ihr Wissen ist nur theoretisch und hat nichts mit der Praxis zu tun.
Verschwenden Sie nicht Ihre Zeit - beherrschen Sie OOP.
Du hast in diesem Forum Hausverbot, mein Freund. :)) Einschließlich mir. :( Verzweifeln Sie nicht - was uns nicht umbringt, macht uns stärker. Ich glaube an Sie!!! :))
Verschwenden Sie nicht Ihre Zeit - beherrschen Sie OOP.
Du bist in diesem Forum komplett gesperrt, mein Freund. :)) Ich auch. :( Verzweifeln Sie nicht - was uns nicht umbringt, macht uns stärker. Ich glaube an Sie!!! :))
Beginnen wir mit der Frage nach der Notwendigkeit von Klassen bei der Implementierung großer Mechanismen. Eine Klasse ist eine Hülle für eine Reihe von Funktionen, und ein "großer Mechanismus" ist ein Codeblock, der eine Reihe von Aufgaben implementiert. In meiner Umsetzung ist eine "Big Machine" fast immer eine sehr große Funktion und eine Reihe kleinerer Funktionen, die ihr dienen. Der so genannte "Motor". Wenn man sie mit Serving-Funktionen in eine Klasse packt, wird sich nichts ändern, und wenn man sie in verschiedene Klassen packt, wird der Zugriff zwischen ihnen komplizierter und die Effizienz des Mechanismus geringer.
Wenn die Größe des Mechanismus zunimmt, ist es notwendig, den Code zu optimieren oder die Funktionalität in Dateien aufzuteilen. Reicht das nicht aus? Außerdem führt die regelmäßige Optimierung des Codes in einem Block zu Wundern der Effizienz. Es wird ständig komprimiert und benötigt immer mehr Funktionen, um umgesetzt zu werden. Das heißt, die Anzahl der Funktionen nimmt im Gegenteil ab. Sie sind in einem Block zusammengefasst, dessen Code ständig verbessert wird. Dies ist ein direkter Weg zur Effizienz .
Wenn wir wichtige Variablen global machen, werden sie überall im Mechanismus sichtbar sein und es wird einfach sein, mit ihnen zu arbeiten, und wenn wir Bereiche für sie definieren, wird das vom Standpunkt der Effizienz des Mechanismus eine überflüssige Aufgabe sein. Auch hier wird der Zugang erschwert. Erstellen von Klassenobjekten, und so weiter... Die Tendenz, den Mechanismus in eine große Anzahl von Funktionen zu unterteilen, ruiniert nicht nur die Effizienz, sondern auch die Universalität der Codeblöcke. Es stellt sich heraus, dass jede konkrete Aufgabe eine eigene Funktion benötigt, und die Universalität von Codeblöcken wird einfach nicht verbessert. Auch die Anzahl der Aufrufe und der übergebenen Parameter nimmt zu. Dies trägt nicht zur Effizienz des Mechanismus bei, aber diese Tendenz wird durch OOP sogar gefördert.
OOP ist effizienter, wenn ein Projekt von einer Gruppe von Programmierern bearbeitet wird. In diesem Fall können Sie nicht auf sie verzichten. Obwohl, wenn man darüber nachdenkt, kann man auch hier einen Weg finden, es zu vermeiden...
Aber das sind natürlich alles nur Worte. In der Praxis würde ich schnell beweisen, wovon ich spreche.
Und daran ist auch etwas dran. Alan Kay, der Schöpfer von OOP, hatte eigentlich eine ganz andere Vorstellung von dem, was man heute unter OOP versteht. Sie ist Ihrer Vision sogar noch ähnlicher. Ich habe die Idee, ein Projekt mit einem Kern und Diensten zu erstellen, die ihn für einige Funktionen aufrufen. Und die Kommunikation zwischen den Elementen wird nur durch Ereignisse - Nachrichten - erfolgen. Sobald Sie eine Ereignisanforderung mit den Daten senden, erhalten Sie die Ereignisantwort mit dem Ergebnis. Es gibt keine Vererbung, keinen Polymorphismus und keine Inklusion.
Übrigens ist es einfacher, Multi-Threading mit diesem Ansatz zu implementieren, da alle Elemente per Definition unabhängig voneinander arbeiten.
Da ist etwas dran. Alan Kay, der Schöpfer von OOP, hatte eine andere Vorstellung von dem, was man heute unter OOP versteht. Sie ist Ihrer Vision sogar noch ähnlicher. Ich habe die Idee, ein Projekt mit einem Kern und Diensten zu erstellen, die ihn für einige Funktionen aufrufen. Und die Kommunikation zwischen den Elementen wird nur durch Ereignisse - Nachrichten - erfolgen. Sobald Sie eine Ereignisanforderung mit den Daten senden, erhalten Sie die Ereignisantwort mit dem Ergebnis. Es gibt keine Vererbung, keinen Polymorphismus und keine Inklusion.
Übrigens ist bei diesem Ansatz das Multithreading einfacher zu organisieren, da alle Elemente per Definition unabhängig voneinander arbeiten.