Immutable View auf StringBuffer?

kirdie

Bekanntes Mitglied
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?
 
Die "immutable view eines StringBuffers" nennt sich: String

StringBuffer ist übrigens der vorläufer von StringBuilder (letzterer ist nciht syncronisiert), aber normalerweise nutzt man String.
 
Na String ist eben kein Immutable View, denn folgendes kann ein String eben nicht:

Java:
import java.util.Collections;
import java.util.LinkedList;
import java.util.List;

public class Main
{
	public static void main(String[] args)
	{
		StringBuffer sb = new StringBuffer();
		sb.append("Hallo Welt");
		String s = sb.toString();
		sb.delete(0, sb.length());
		sb.append("Hallo Schmelt");
		System.out.println(s);

		List<String> list = new LinkedList<String>();
		list.add("Hallo Welt");
		List<String> unmodifiableList = Collections.unmodifiableList(list);
		list.clear();
		list.add("Hallo Schmelt");
		System.out.println(unmodifiableList);
	}
}

Output:
Java:
Hallo Welt
[Hallo Schmelt]
 
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..
 
Zuletzt bearbeitet von einem Moderator:
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.
 
Zuletzt bearbeitet:
was du am Programm auszusetzen hast und eigentlich erwartest verrätst du nicht, tolle Sache..
Doch, das schreibe ich doch ganz am Anfang.

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

Aber ich schreibe es noch mal ganz ausführlich:

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 = new Anzeige(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.

Doch doch, nur das er eben seinen Wert nie ändert 😉
IMHO ist deine Nutzung des StringBuffers nicht im Sinne des Erfinders..

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.
 
Zuletzt bearbeitet:
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?
 
Du machst es dir vielleicht kompliziert...
Was wäre so tragisch ein einer Language Klasse mit einer
Code:
String getLanguage()
Methode?
Wenn du Lust hast kannst du für deren Implementierung sogar einen StringBuilder als Member verwenden, auch wenn das reichlich sinnlos ist...
 
@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.
 
Dann nenne sie ImmutableStringView anstatt Language. Die Funktionalität bleibt die gleiche.
Wenn man keine echten Problem hat sucht man sich welche 🙂
 

Zurück
Oben