Sollte ich eine einzelne oder mehrere Skriptdateien haben?

Question

Ich erstelle ein Programm in Java, das Skripting verwendet. Ich frage mich nur, ob ich meine Skripte für jedes Skript in eine Datei aufteilen sollte (realistischer jede Art von Skript wie "Mathe-Skripte" und "Account-Skripte" usw.), oder wenn ich eine verkleinerte Datei für alle Skripte verwenden sollte.

Ich bin auf der Suche nach einer Antwort aus eher einem technischen Standpunkt als eine praktische Sicht, wenn möglich, da this Frage Art bereits erklärt die praktische Seite (separate oft modifizierte Skripte und große Skripte).

Answer 1

In Bezug auf die Auswirkungen auf die technische Leistung könnte man argumentieren, dass die Verwendung einer einzelnen Globals-Instanz tatsächlich effizienter ist, da alle Bibliotheken nur einmal statt mehrmals geladen werden. Allerdings hängt die Frage nach der Verwendung mehrerer Dateien wirklich ab. Mehrere physische LUA-Dateien können mit den gleichen Globals geladen werden, oder eine einzelne Datei kann mit der Globals-Instanz geladen werden, so wie die Globals-Tabelle am Ende die gleiche Menge an Daten enthält, unabhängig davon, ob sie aus mehreren Dateien geladen wurde oder nicht. Wenn Sie mehrere Globals für jede Datei verwenden, ist dies nicht der Fall.

Fragen wie diese hängen wirklich davon ab, was die beabsichtigten Ziele sind, die Sie für lua verwenden möchten. Die Verwendung einer einzelnen Globals-Instanz wird RAM effizienter nutzen, aber darüber hinaus wird es keine Leistungssteigerung geben. Das Laden mehrerer Dateien im Vergleich zu einer einzelnen Datei kann etwas länger dauern, da die Zeit zum Öffnen und Schließen der Dateihandles etwas länger ist, aber dies ist eine solche Mikrooptimierung, dass es den Aufwand für das Schreiben des gesamten Codes in eine einzige Datei nicht wert ist. ganz zu schweigen davon, wie schwer es wäre, es effizient zu organisieren.

Es gibt jedoch einige Vorteile bei der Verwendung mehrerer Globals. Jede Globals-Instanz verfügt jedoch über einen eigenen globalen Speicher, sodass Änderungen wie das Überladen von Operatoren für Objekte mit überlagerbaren Funktionen nicht auf andere Instanzen übertragen werden. Wenn dies für Sie kein Problem darstellt, kann es sinnvoll sein, den Code in mehrere Dateien zu schreiben und alle mit einer einzigen Globals-Instanz zu laden. Wenn Sie dies tun, achten Sie jedoch darauf, alle Ihre Dateien richtig zu strukturieren. Wenn Sie den globalen Gültigkeitsbereich häufig verwenden, kann es schwierig werden, Objektnamen zu verfolgen und Werte aus anderen Dateien versehentlich zu ändern. Um dies zu vermeiden, kann jede Datei ihre gesamte Funktionalität in einer eigenen Tabelle definieren, und dann arbeiten diese Tabellen als einzelne Module, in denen Sie Features basierend auf den Tabellen auswählen können, fast so, als würden Sie aus einer bestimmten Datei auswählen.

Am Ende macht es wirklich keinen großen Unterschied, aber je nach dem, was Sie wählen, müssen Sie darauf achten, eine gute Organisation des Codes sicherzustellen. Wenn mehrere Globals verwendet werden, wird mehr RAM benötigt, aber jede Datei kann ihre eigenen benutzerdefinierten Bibliotheken haben, ohne dass andere betroffen sind. Dies wird jedoch dadurch verursacht, dass das Java-Ende der Software mehr strukturelles Management erfordert, damit alle Dateien organisiert bleiben.

Verwenden eines einzigen Globals benötigt weniger RAM, aber alle Dateien haben den gleichen globalen Geltungsbereich, was benutzerdefinierte Versionen von Bibliotheken schwieriger macht und eine strukturellere Organisation von der Lua-Seite der Software erfordert, um zu verhindern, dass Namen und andere Funktionen in Konflikt geraten.

Wenn Sie beabsichtigen, dass andere Benutzer Ihre Lua-API zum Hinzufügen zu Ihrer Software über ein Add-On-System verwenden, möchten Sie möglicherweise mehrere Instanzen von Globals verwenden, da der Benutzer Addons erstellen muss, die dafür verantwortlich sind Sicherzustellen, dass der Code keinen Konflikt mit anderen Addons darstellt, ist nicht nur gefährlich, sondern auch eine Last, die nicht existieren muss. Ein unerfahrener Benutzer kommt mit dem Versuch, ein Addon zu machen, organisiert es nicht richtig und kann Teile der Software oder Software-Addons vermasseln.