[Design]Klasse unveränderlich oder doch sperren?
-
Hallo,
wir sind gerade am Diskutieren welches Design (für Lib.) nun nutzbringender im Sinne der Anwender ist. Eine Klasse unveränderlich zu gestalten oder aber mit Sperren (Mutex,...) zu arbeiten. Für unveränderliche Klassen fallen mir die beiden Stringklassen in Java und C# ein, mit denen es sich recht gut arbeiten lässt. Wir suchen nicht die ultimative Lösung sondern nur ein paar Anregungen.
leftshift
-
Das hängt davon ab, wie sehr das Arbeiten mit Threads für diese Bibliothek überhaupt vorgesehen ist. Und es hängt auch von der Komplexität und Modularität ab. Wenn eure LIB irgendwelche komplexen Operationen ausführt, fände ich es angebrachter, dass sie threadsicher ist, als wenn sie nur irgendein anderer Container ist. Und wenn sie nicht ständig für Threads benutzt wird, würde ich auch nicht unnötig Aufwand hineinstecken.
-
Die Benutzung in einer Threadumgebung ist sehr wahrscheinlich. Heute im Zeitalter der 'Multicorerechner' diesen Umstand nicht zu berücksichtigen wäre sehr kurzsichtig. Die ganze Lib wird ein Container von über Jahren bewährten Algorithmen aber eben sauber in Klassen gepackt (bis jetzt alles Einzelkämpfer).
-
leftshift schrieb:
Die ganze Lib wird ein Container von über Jahren bewährten Algorithmen aber eben sauber in Klassen gepackt (bis jetzt alles Einzelkämpfer).
Was ist an Algorithmen schlecht, wenn sie nicht in Klassen stehen? Beachte, dass die meisten Algorithmen der STL freie Funktionen sind.
-
Ist schon klar das wir nicht alles(!) in Klassen packen. Ich sage nur über Jahre gewachsener Wildwuchs.
-
Namespaces?
