Sinnhaftigkeit als *so

[Maik81SE]

Moin Zusammen,
Ich bin gerade dabei meine Sammlung wieder aufzuräumen und Sammlungschaos von meinen Test's zu bereinigen.
Dabei bin ich auf wiederkehrende Zeilen in meinen Tests gestoßen, welche sich auch in meinen Programmen befinden und frage, ob es sinvoll ist, auf diesen Funktionen eine lib zu bauen.

Anbei stelle ich mir 2 Fragen.
[*] Müsste ich etwas beachten, wenn ich iwan für Android/iOS schreiben will? abgesehen davon, das ich die libs jeweils mitgeben muß
[*] Wie würden sich Klassen in einer lib verhalten. (Aufrufverhalten/Verhalten und co)
[*] Wie verhielten sich Strings als Parameter? Ich weiß, das es da das ein ein oder andere Problem gab, ist aber schon ein paar Monde her, das ich damit gearbeitet habe.

Nachteil an der Thematik?
Ich müsste immer die libs mitgeben/übertragen.

Vorteil?
Das Programm dürfte sich, wenn ich es richtig auf dem Zettel habe um die menge, welche ich eine lib aufgelagert wird schrumpfen.

Im Klartext...
in jeder Class, welche ich für meine *.config* nutze verwende ich zB diese Zeilen.

Code: Alles auswählen

constructor Tclassname.Create;
begin
  inherited;
  PConst.fExt			  := 'Settings';
  PConst.fProg			  := 'VeeJee';
  PConst.fFilename                := Set_FileName(PConst.fExt, PConst.fProg, false, false);
  // Weitere Funktion und Grundlegende Settings
end;

die Function

Code: Alles auswählen

Set_FileName(Ext, Prog: String; Global, Subdir: Boolean): String;

hab ich schon erst mal ausgelagert, da auch meiner einer bekennend schreibfaul ist.
Bin jedoch nicht wirklich 100 prozentig glücklich damit

[af0815]

Warum will jeder auf Libs (egal ob .so oder .dll) gehen ?! Freepascal/Lazarus haben ein bereits ein solches System und zwar in den Units bzw. Komponenten eingebaut.

Ich verwende hier bei mir (in der Firma) eine riesige lib in Unit bzw. Komponentenform. Die erstreckt sich Themenabhängig über einen kompletten Verzeichnisbaum. Zusätzlich liegt die in einem GIT und wenn externe Komponenten eingebunden, auch über eigebundene SubGITS. Die SubGITS würden auch als extra Baumstruktur außerhalb verwenden lassen. Alles was OPM ist, liegt nicht im GIT.

Komponenten die in Libs liegen sind nicht so einfach zu handhaben, dazu hat es in letzter Zeit doch einiges an Diskussion gegeben. Dort wo es unbedingt nötig ist, weil man für andere Sprachen/Programme ein Plugin schreiben muss, sind ja ok und man muss dann mit den Nebeneffekten leben lernen.

[corpsman]

Ich bin auch kein Fan von Libs, gerade weil ich sehr viel Plattformunabhängig schreibe müsste ich dann ja jedesmal eine separate .dll oder .so oder .dylib bauen.

Übrigens Strings kriegt man mittels Pchar in eine DLL und auch wieder Raus. Bei Klassen wäre ich da vorsichtig ...

Ähnlich wie af0815 habe ich ettliche "kleine" units verteilt auf eine mehr oder weniger Sinnvolle Ordnerstruktur. Wie das aussieht könnt ihr sogar ansehen, denn ich bin seit einiger Zeit dabei diese "Units" auf meiner Github Seite der Allgemeinheit zur Verfügung zu stellen.

[af0815]

Moin Zusammen,
Ich bin gerade dabei meine Sammlung wieder aufzuräumen und Sammlungschaos von meinen Test's zu bereinigen.
.......
die Function

Code: Alles auswählen

Set_FileName(Ext, Prog: String; Global, Subdir: Boolean): String;

hab ich schon erst mal ausgelagert, da auch meiner einer bekennend schreibfaul ist.
Bin jedoch nicht wirklich 100 prozentig glücklich damit

Wenn du damit nicht glücklich bist, dann hast du noch nicht die richtige Mischung an den Schnittstellen gefunden. Richtig ist sowas wie die Units von LCL/FCL, die verwendet man ohne viel nach zu denken. Aber Achtung, wenn du was in eine solche Bibliotheks Unit schreibst, darfst du später nichts mehr daran herummurksen, ansonsten lassen sich die Programme die das verwenden nicht mehr sauber verwenden. Genaugenommen sollte man sich gleich einen Unittest damit erstellen und nur solche Änderungen zulassen, die auch den Test später bestehen. (Ist ja auch bei der LCL so ähnlich).
Weil ein grober Fehler ist, diese selbst geschaffenen Bibliotheken, je nach Laune zu ändern, das gibt garantiertes Chaos. Die Selbstdisziplin ist später dann dringend nötig.

[Maik81SE]

Danke euch beiden für das Feedback,

nachdem man nochmal eine Nacht darüber geschlafen hat, ist man zu dem Entschluss gekommen, die Sammlung wie gehabt weiter mit Units aufzubauen.

[Mathias]

nachdem man nochmal eine Nacht darüber geschlafen hat, ist man zu dem Entschluss gekommen, die Sammlung wie gehabt weiter mit Units aufzubauen.

Genau so mache ich es auch, eine lib würde ich höchstens machen, wen ich sie für C zur Verfügung stellen müsste.
Mit den Units ist man Plattform unabhängig und müssen nicht für die verschiedene Plattformen gepflegt werden, Ausnahmen vorbehalten.
Man beachte auch das Chaos, was die C-Freunde haben.

[Maik81SE]

nachdem man nochmal eine Nacht darüber geschlafen hat, ist man zu dem Entschluss gekommen, die Sammlung wie gehabt weiter mit Units aufzubauen.

Genau so mache ich es auch, eine lib würde ich höchstens machen, wen ich sie für C zur Verfügung stellen müsste.
Mit den Units ist man Plattform unabhängig und müssen nicht für die verschiedene Plattformen gepflegt werden, Ausnahmen vorbehalten.
Man beachte auch das Chaos, was die C-Freunde haben.

Damit sprichst du gerade ein Faktor an, den ich vor 3?! Jahren ab Akta Gelegt habe, und noch einen Reminder auf den Weg gegeben.
All meine C-Files in Pascal umzuschreiben. , sofern nicht schon geschehen.