Welches Paradigma ist besser für das Design und die Analyse von Algorithmen? Was ist schneller? Weil ich ein Fach mit dem Namen Design and Analysis of Algorithms in der Universität habe und ein Zeitlimit für Programme habe. Ist OOP langsamer als das Procedure-Programmieren? Oder der Zeitunterschied ist nicht groß?OOP vs PP für Algorithmen
IMO-Algorithmen existieren getrennt vom OO- oder PP-Problem.
Weder OO noch PP sind "langsam", weder in der Entwurfszeit noch in der Programmausführung, sie sind unterschiedliche Ansätze.
Für Design, Analyse und Entwicklung: definitiv OOP. Es wurde feierlich zum Nutzen von Designern und Entwicklern erfunden. Für die Programmlaufzeitausführung: manchmal ist PP effizienter, aber oft wird OOP vom Compiler auf einfache PP reduziert, was sie äquivalent macht.
Der Unterschied (in Ausführungszeit) ist bestenfalls marginal.
Beachten Sie, dass es einen wichtigeren Faktor als reine Leistung gibt: OOP bietet dem Programmierer bessere Möglichkeiten, seinen Code zu organisieren, was zu Programmen führt, die gut strukturiert, verständlich und zuverlässiger sind (weniger Bugs).
Ich würde denken, dass Functional Programming sauberere Implementierung von Algorithmen erzeugen würde.
Nachdem das gesagt wurde, sollten Sie keinen großen Unterschied sehen, egal was Sie angehen. Ein Algorithmus kann in beliebigen Sprache oder Entwicklung Paradigma ausgedrückt werden.
aktualisieren: (folgenden Kommentar)
Anscheinend funktionale Programmierung macht nicht selbst verleihen Algorithmen als auch auf die Umsetzung, wie ich dachte, es kann. Es hat andere Stärken und ich erwähnte es meistens aus Gründen der Vollständigkeit, da die Frage nur OOP (objektorientierte Programmierung) und PP (prozedurale Programmierung) erwähnt.
Meine Vermutung ist, dass der Unterschied nicht groß genug ist, um sich zu sorgen, und das Zeitlimit sollte erlauben, eine langsamere Sprache zu verwenden, da der verwendete Algorithmus wichtig wäre. Der Zweck der Frist sollte IMO sein, um Sie mit zum Beispiel zu vermeiden, dass ein O (n) Algorithmus, wenn ein O (n log n)
Objektorientierte Programmierung viele Low-Level-Details abstrahiert von der Programmierer. Es ist mit dem Ziel entwickelt,
Procedural Programmierung hat nicht viele Abstraktionen wie Objekte, Methoden, virtuelle Funktionen usw.
Also, reden über Geschwindigkeit: ein erfahrener Experte, der die Interna wie ein objektorientiertes System weiß, arbeiten kann ein schreiben Programm, das genauso schnell läuft.
Der Geschwindigkeitsvorteil, der durch die Verwendung von PP über OOP erreicht wird, ist sehr gering. Es läuft darauf hinaus, auf welche Weise Sie Programme bequem schreiben können.
EDIT:
Eine interessante Anekdote kommt mir in den Sinn: in den Microsoft Foundation Classes, von einem Objekt zum anderen vorbei Nachricht wurde unter Verwendung von Makros implementiert, wie BEGIN_MESSAGE_MAP sah() und END_MESSAGE_MAP(), und der Grund war, dass es schneller war als virtuelle Funktionen.
Dies ist ein Fall, in dem die Bibliothek Entwickler OOP verwendet haben, aber einen Leistungsengpass wissentlich ausgewichen.
das schwache Glied ist liekly Ihr Wissen zu sein - welche Sprache & Paradigmen sind Sie am bequemsten mit. verwenden, dass
Objektorientierte Programmierung Algorithmen nicht besonders relevant ist. Prozedurale Programmierung werden Sie brauchen, aber in Bezug auf Algorithmen ist objektorientierte Programmierung nur eine weitere Möglichkeit, die prozedurale Programmierung zu verpacken. Sie haben anstelle von records/structs Methoden anstelle von Funktionen und Klassen, aber der einzige relevante Unterschied ist die Laufzeitverteilung, und das ist nur eine deklarative Methode zur Behandlung einer Laufzeitentscheidung, die auf andere Weise hätte behandelt werden können.
Objektorientierte Programmierung ist mehr relevant für den größeren Maßstab - Design Patterns usw. - während Algorithmen mehr relevant für den kleineren Maßstab sind eine kleine Anzahl (oft nur eine) des Verfahrens beteiligt ist.
Absolut. Bei OO geht es mehr um die Struktur des App-Designs als um alles andere. – kyoryu
Um das Schreiben von Code einfach und weniger fehleranfällig zu machen, müssen Sie eine Sprache, den Generics unterstützt - wie C++ mit STL oder Java mit dem Java Collections Framework. Wenn Sie einen Algorithmus gegen eine Deadline implementieren, können Sie möglicherweise Zeit sparen, indem Sie Ihren Algorithmus nicht mit einer netten O-O- oder Generic-Schnittstelle versehen, so dass der Code, den Sie selbst schreiben, vollständig prozedural ist.
Für Laufzeiteffizienz, würden Sie wahrscheinlich am besten schriftlich alles in Verfahren C - siehe z.B. die Beispiele in "Die Praxis des Programmierens" - aber es wird viel länger dauern zu schreiben, und Sie werden eher Fehler machen. Dies setzt auch voraus, dass alle Bausteine, die Sie benötigen, auch in der Prozedur C aktuell und effizient zur Verfügung stehen, was heutzutage eine ziemliche Annahme ist. Wahrscheinlich wird die Verwendung der STL oder der JFC in der Praxis sparen Sie CPU-Zeit sowie Entwicklungszeit.
Ich erinnere mich, dass funktionale Programmierung Enthusiasten darauf hinweisen, wie viel einfacher ihre Sprachen zu verwenden als die Konkurrenz waren, und dann zu beobachten, dass diejenigen Mitglieder der Klasse, die eine funktionale Sprache gewählt hatten, immer noch kämpften in Fortran 77 war fertig und fuhr fort, Graphen der Leistung ihres Programms zu zeichnen. Ich sehe, dass sich die Ansprüche der funktionalen Programmiergemeinschaft nicht geändert haben. Ich weiß nicht, ob die zugrunde liegende Realität hat.
Ich stimme überhaupt nicht überein über die "länger zu schreiben und wahrscheinlicher, Fehler zu machen" Aussage, wenn sie auf C. bezieht. Es hängt sehr davon ab, worüber wir sprechen. OOP bietet einige große Vorteile beim Schreiben großer Benutzer-Apps mit vielen Benutzerinteraktionen, bei denen die Daten/Eingabe dynamisch und unbekannt ist (Verwendung von Generika). Aber für viele andere Systeme ist Schreiben in Vanille C sauberer, einfacher, schneller und weniger fehleranfällig. Vor allem in eingebetteten Systemen. – Awaken
@Awaken - im Kontext stimme ich zu. Im Großen und Ganzen ist natürlich C ein C++ - Programm, so dass Sie C++ schreiben können, als wäre es C, aber dieses Extra-Tool immer noch verfügbar, wenn es benötigt wird. C++ ist nicht Java - Sie müssen nicht alles in eine Klasse einbinden, Sie erhalten standardmäßig keinen Laufzeitversand, usw. – Steve314
@mcdowella - Es gibt einige gute solide unreine funktionale Sprachen.Haskell ist "rein" und ziemlich gut, aber ich würde argumentieren, dass Haskell wegen Monaden unrein ist - und während die Idee sehr interessant ist, mag ich monadischen Pseudo-Imperativ-Code, der rein funktional übersetzt wird, nur nicht zu sein zurück in den Imperativ übersetzt, mit zwei Schichten undichter Abstraktion zwischen der imperativen Quelle und der imperativen Maschine. IMO das funktionale Toolkit ist sehr gut, aber Sie brauchen auch das imperative Toolkit. Auch funktionale Sprachen sind gewöhnungsbedürftig. Vertrautheit ist der Schlüssel. – Steve314
Steve314 sagte es gut. Bei OOP geht es mehr um die Entwurfsmuster und die Organisation großer Anwendungen. Außerdem können Sie mit Unbekannten besser umgehen, was für Benutzer-Apps großartig ist. Bei der Analyse von Algorithmen werden Sie jedoch höchstwahrscheinlich funktional darüber nachdenken, was Sie tun möchten. In diesem Fall würde ich bei einfacheren PP bleiben und nicht versuchen, ein vollständiges OO-Design zu erstellen, wenn Sie sich um den Algorithmus kümmern. Ich würde gerne mit C oder Matlab arbeiten (je nachdem wie mathematisch der Algorithmus ist). Nur meine Meinung dazu.
Ich habe einmal den String-Suchalgorithmus Knuth-Morris-Pratt angepasst, so dass ich ein Objekt haben könnte, das ein Zeichen nach dem anderen nehmen und einen Match/No-Match-Status zurückgeben würde. Es war keine geradlinige Übersetzung.
stimme ich nicht zu. Algorithmen sind grundlegend über * wie * Sie etwas tun.Der Standardanspruch über funktionale Programmierung ist, dass Sie angeben, was Sie wollen, nicht wie Sie es tun. Insbesondere sind In-Place-Aktualisierungen für viele Algorithmen wesentlich. Mit der funktionalen Programmierung versuchst du im Grunde zu versuchen, * den Algorithmus, den du brauchst, zu implizieren * und hoffst, dass der Compiler/Optimierer die Implikation aufgreift. – Steve314
Zum Beispiel hat die gesamte funktionale Programmiergemeinschaft jahrelang völlig versäumt zu erkennen, dass die normale funktionale Umsetzung des Siebs von Eratosthenes (ein sehr einfacher und gut verstandener Algorithmus) einfach * das Sieb oder Eratosthenes gar nicht und vollständig war die falsche Komplexität. Wenn Tausende von intelligenten Menschen nicht erkennen, dass ein einfacher Algorithmus nicht das ist, was er zu sein vorgibt, wissen Sie, dass Sie keine saubere oder klare Methode zur Beschreibung von Algorithmen haben. – Steve314
Jahrzehntelang (bis heute) konnte die gesamte prozedurale Programmiergemeinschaft nicht erkennen, dass die normale prozedurale Implementierung der Integer-Arithmetik (eine sehr einfache und gut verstandene Arithmetik) überhaupt keine Integer-Arithmetik war und völlig falsch war Ergebnisse. Wenn Dutzende von Millionen intelligenter Menschen nicht erkennen, dass eine einfache Arithmetik nicht das ist, was sie zu sein vorgibt, wissen Sie, dass Sie keine saubere oder klare Art haben, die Arithmetik zu beschreiben. BTW: Die meisten Sieve, die ich gesehen habe, waren falsch, unabhängig davon, ob sie funktional, prozedural, OO, Logik, ... implementiert wurden. –