OO-System ist ein freies, quelloffenes Paket für OOP in Mathematica. Durch den Einsatz von OO-System hoffe ich, das Beste aus beiden Welten (OOP/Funktional) nutzen zu können.
Ein Disclaimer: Ich habe keine der bestehenden OO-mma-Erweiterungen (und OO System im Besonderen) verwendet, so dass dieser Beitrag auf allgemeinen Argumenten basiert (aber ich habe OO intensiv genutzt, als ich in Java gearbeitet habe, und einige OO-Elemente in mma verwendet, die ich selbst implementiert habe). Ich stimme zu mit dem Stellungnahme dass OO ein bewegliches Ziel ist, so dass man die gewünschten Funktionen genauer beschreiben muss, um eine brauchbare Antwort zu erhalten. Es hängt auch stark davon ab, welche Ziele Sie verfolgen - wollen Sie Ihr eigenes Leben vereinfachen und Ihr eigenes Projekt skalierbar machen, oder wollen Sie die Kommunikation für das Projekt vereinfachen, das von mehreren (vielen) Entwicklern entwickelt wird, und bestimmte Regeln und Protokolle (Codierungsstandards, Best Practices, Design Patterns, was auch immer) durchsetzen, oder wollen Sie, dass OO bestehende Bibliotheken wiederverwendet.
Ich würde behaupten, dass die meisten OOP-Anwendungen in der Industrie in die zweite und dritte Kategorie fallen. Wenn dies auch bei Ihnen der Fall ist (was ich nicht vermute), dann kann es Sinn machen, OOP in Mathematica zu verwenden, obwohl selbst das nicht klar ist. WolframAlpha zum Beispiel hat zig Millionen Codezeilen in seiner Codebasis, und AFAIK wurde dort kein OO-System verwendet. Wenn Sie die Vorteile für den Einzelentwickler wollen, dann würde ich die Funktionen von OO auswählen, die mir gefallen, und sie selbst implementieren - d.h. Ihr eigenes Objektmodell erstellen. Das ist in Mathematica nicht allzu schwierig.
Es wäre viel sinnvoller, eine spezielle OO-Erweiterung von Mathematica zu verwenden, wenn es eine große Anzahl von gut getesteten Open-Source-Bibliotheken gäbe, die mit dieser Erweiterung gebaut wurden, mit einem einfachen Bereitstellungsmechanismus. Mir ist keine nennenswerte mma-Codebasis (Bibliotheken) bekannt, die mit einer der bestehenden OO-mma-Erweiterungen erstellt wurde (was auch an meiner Unwissenheit liegen könnte). Wenn Sie also OO benötigen, um bestehende Bibliotheken wiederzuverwenden, dann sind Dinge wie J/Link oder .Net/Link vielleicht besser für Sie geeignet, da Sie Zugang zu Java oder .Net haben werden.
Wenn Sie Ihr Projekt skalieren wollen, dann ist OO nicht Ihr einziger Freund. Obwohl dies wahrscheinlich kein sehr gut erforschtes Gebiet für mma ist (außer vielleicht von WRI), können einige Techniken aus anderen funktionalen Sprachen, wie z.B. Closures, LISP-Makros, Codegenerierung zur Laufzeit usw., durchaus auf mma anwendbar sein. Eines der mma-Projekte, an denen ich arbeite, hat zum Beispiel mehr als 40 Pakete und mehr als 10.000 Zeilen mma-Code, und es ist recht überschaubar (mit WorkBench). Ich verwende häufig Closures und Makros, und auch einige OO-Funktionen, aber keine generische OO-Erweiterung. Die wichtigsten Dinge sind das Verstecken von Informationen, eine geringe Kopplung, Kompositionsfähigkeit und Testbarkeit, und auch hier ist OO nicht der einzige Weg, dies zu erreichen.
IMO wäre eine sehr schöne Sache, die durch eine OO-fähige Sprachschicht in mma (vielleicht ähnlich wie Python) erreicht werden könnte, die Komplexität des Evaluators und des Pattern-Matchers zu verbergen, da diese in vielen Fällen nicht benötigt werden und für weniger erfahrene Benutzer verwirrend sein können. Ich vermisste (und vermisse immer noch) eine solche Sprachebene zuweilen sehr. Der Designer einer solchen Schicht wird vor der schwierigen Aufgabe stehen, sie wirklich gut mit dem Rest von mma zu integrieren. Abgesehen davon sehe ich die zwei größten Hindernisse für ein generisches OO-System, das in der obersten Ebene von mma aufgebaut ist: langsame Leistung und keine automatische Garbage Collection. Ich denke, solange diese Probleme nicht gelöst sind, schließen sie eine intensive Nutzung von OOP in der Produktion auf der unteren Ebene aus (Erstellung von Millionen von Objekten usw.). Einige Funktionen der OOP können für die Architektur von Projekten auf hoher Ebene immer noch recht nützlich sein, aber wie ich schon sagte, sind sie leicht zu implementieren. Das soll nicht heißen, dass Sie bestehende OO-Erweiterungen nicht ausprobieren sollten, ich würde nur ihre Vorteile speziell für mma gegen die notwendigen Einschränkungen abwägen, die sie Ihrem Code auferlegen werden.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
