TLDR: Gibt es in der Standard-API eine Möglichkeit, einen Immutable View auf einen StringBuffer zu erstellen?
Ausführlich: In meinem Programm kann der Nutzer mit einer drop down Liste eine Sprache auswählen und auch später noch ändern. Ein anderer Teil des Programms nutzt diese Sprache nun zur Anzeige. Daher habe ich mich für einen StringBuffer entschieden. Um jedoch zu vermeiden, dass der Anzeigeteil die Sprache ändert, würde ich gerne einen Immutable View übergeben. Ist das möglich?
dein Beispiel zeigt, dass String s den Inhalt "Hallo Welt" aus dem StringBuilder vor der Änderung zu 'Hallo Schmelt' gerettet hat,
klingt eher positiv?
und dass Collections.unmodifiableList() nicht die darunterliegende Liste von Änderungen schützt, wenn auf diese normal zugegriffen wird,
was weder mit String und schon gar nicht mit StringBuilder allzu viel zu tun hat,
was du am Programm auszusetzen hast und eigentlich erwartest verrätst du nicht, tolle Sache..
Ich verstehe jetzt auch nicht gerade den Zusammenhang zwischen dem String und der Collection. Natürlich ist der String immutable. Außerdem sagt die API der Collectionsklasse in Bezug auf diese Methode, das Funktionen, die auf der resultierenden Liste manipulieren eine Exception werfen, was in diesem Beispiel auch gut vorgeführt wird.
Da es um Sprachressourcen geht, schau dir doch mal Locales und das ResourceBundle aus dem Standard-Java an.
In meinem Programm kann der Nutzer mit einer drop down Liste eine Sprache auswählen und auch später noch ändern. Ein anderer Teil des Programms nutzt diese Sprache nun zur Anzeige
Es gibt eine Variable "languageTag", die die Sprache des Programms enthält, also z.B. "en", "de", "us" und so weiter.
Durch eine drop down Liste ist diese Sprache auswähl- und änderbar.
Ein anderer Teil des Programmes zeigt jetzt je nach der ausgewählten Sprache unterschiedliche Sachen an, z.B. wenn die Sprache "en" ist "Munich" und ansonsten "München", diese Daten sind aber nicht vorgespeichert sondern werden aus dem Semantic Web geholt (deshalb geht auch sowas wie locales da nicht weil ich die Daten ja erst abrufe).
Wenn ich jetzt den Anzeigeteil instanziiere, dann übergebe ich die Sprache. Aber das geht nicht mit einem String, weil sich die Sprache ja ändert.
Java:
Anzeige anzeige =newAnzeige(sprache);
Wenn ich aber Anzeige einen StringBuffer übergebe, dann kann die Klasse Anzeige aber theoretisch die Sprache ändern, aber das darf sie natürlich nicht, deshalb geht ein StringBuffer auch nicht.
Was ich also brauche ist ein "immutable view" (d.h. die Sicht ist unveränderlich, das Objekt nicht), was ich nicht brauche ist ein unveränderliches Objekt.
StringBuffer sind doch veränderliche Strings oder? Und genau das habe ich ja.
P.S.: Achso, um nochmal das Beispiel zu erklären. Das Verhalten von der Liste ist mein Wunschverhalten. Das ist auch Absicht, dass ich die Liste ändere und das durchgeht, nur brauch ich eben keine Liste sondern einen String.
Du arbeitest gerade an Java vorbei, String sind immutable aus gutem Grunde, was du eigentlich willst ist ein Mechanismus der dafür sorgt, dass die Anzeige sich ändert wenn sich die Sprache ändert, schon mal "Listener" und MVC gehört?
Die JavaBeans spek bietet da etwas: PropertyChangeSupport
Ich weiß, dass ich sowas auch mit Listenern machen kann aber ich möchte halt nicht 20+ Zeilen Code haben, wenn ich es auch mit einer Codezeile machen kann. Die Anzeige muss ja nicht sofort die Sprache umstellen, es reicht mir, wenn es beim nächsten Aufruf aktualisiert wird. Also du meinst, es wäre besser, das mit Listenern zu machen, als jetzt selbst einen Immutable View auf einen StringBuffer zu schreiben?
@Wildcard: Ich schreibe lieber eine Klasse mit allgemeiner Funktionalität, die ich dann mehrfach verwenden kann, als für jeden Spezialfall eine extra Klasse mit nur einer Variablen drin zu haben. So ein Immutable View hätte ja auch noch weitere Verwendungszwecke, während eine "Language" - Klasse nur genau den einen hätte.