Dazu kommt, dass man die Schnittstelle zur
DLL auch bei Erweiterungen nicht ändern muss, sondern auf verschiedene Versionen eines Interfaces prüfen kann, so also zwischen verschiedenen Versionen der
DLL und des Hostprogramms kompatibel ist. Wenn man das denn möchte.
Für uns ist es keine Einschränkung, dass EXE und
DLL immer in derselben Umgebung kompiliert werden müssen.
Vor allen braucht man sich aber nicht darum zu kümmern, dass der Speicher der übergebenen Objekte nicht zu früh oder zu spät freigegeben wird usw., da das automatisch passiert, wenn die Referenzen z.B. auf nil gesetzt werden. Gerade bei mehreren beteiligten Modulen ist das sehr hilfreich.
Auch das ist keine Einschränkung. Der Speicher, sprich erstellen und freigeben, wird immer nur in der EXE gemacht. Aktuell ist die Vorstellung, dass die EXE den gesamten Prüfablauf und die Felder für erwartete Ergebnisse generiert. Die
DLL füllt dann diese Felder mit Messergebnissen. Im Beispiel die Power bei der vorgegebenen Prüflast.
Das wäre was anderes, wenn man auch die Intelligenz, den Prüfablauf zu generieren, in die
DLL verlegen würde was wir aber vermieden haben um einen eindeutigen Master of the Class zu haben. Eine Einschränkung mit der wir leben können, wenn dadurch das Klassenhandling sicher ist.