Frage zur Übergabe von Strings

[Arbon]

Hallo. Ich habe eine Klasse FileTypeOptions welche ein Panel mit einigen Optionen erzeugt. Dieser Klasse werden 3 String übergeben. Da Strings ja Objekte sind, sollte sie per Referenz übergeben werden. Wenn ich allerdings in dieser Klasse die Strings ändere, wird der String der übergeben wurde nicht geändert. Woran liegt das?

package gecko.view;

import stuff...

public class FileTypeOption extends JPanel {

	private Logger log;

	private String type;
	private String orig;

	private JButton rst;
	private JTextField txt;

	public FileTypeOption(String name, String type, final String orig) {
		log = LogManager.getLogger(getClass());
		log.debug("Initialisiere " + getClass());

		this.type = type;
		this.orig = orig;

		createPanel(name);

		log.debug(getClass() + " wurde initialisiert");
	}

	private void createPanel(String name) {

		txt = new JTextField(type);
		txt.setPreferredSize(new Dimension(200, 25));
		txt.addActionListener(new ActionListener() {
			@Override
			public void actionPerformed(ActionEvent e) {
				type = txt.getText();
			}
		});

		rst = new JButton("Reset");
		rst.addActionListener(new ActionListener() {

			@Override
			public void actionPerformed(ActionEvent e) {
				txt.setText(orig);
				type = orig;
			}

		});

		add(new JLabel(FileTypeManager.getSmallIcon(name)), BorderLayout.WEST);
		add(txt);
		add(rst, BorderLayout.EAST);
	}

}

Wobei es so aufgerufen wird

		typePan.add(new FileTypeOption("application",
				options.FILE_TYPE_APPLICATION,
				options.FILE_TYPE_APPLICATION_ORIG));

options.FILE_TYPE_APPLICATION ist NICHT final, sondern NUR public

mfg

 

[Schandro]

String ist immutable, ein String-Object kann sich nicht verändern. Deswegen geben auch alle Methoden die man auf ein String-Object aufrufen kann (wie z.b. substring) immer ein neues String Object zurück. Das String-Object, auf das die Methode aufgerufen wurde, hat sich nicht verändert.

 

[Arbon]

Wie könnte man dies sonst machen?
mir wäre die Idee gekommen es mittels Reflection zu machen, aber wäre dies eine halbwegs saubere Lösung oder gibt es da etwas besseres?

 

[Schandro]

die passive Lösung (aus Sicht der Klasse FileTypeOption):
du erstellst in der Klasse FileTypeOption einige Getter für die Strings, die können dann jederzeit von außen abgerufen werden.

die aktive:
Du benutzt das Observer-Pattern. Das heisst du gibts FileTypeOption eine Art Listener im Konstruktor mit der innerhalb von FileTypeOption mit den neusten Strings als Parameter aufgerufen werden kann sobald sich was wichtiges geändert hat.

 

[Arbon]

Das Problem bei der sache ist, die Strings liegen in einer Klasse mit diversen Optionen, welche von sonstigem Zeug relativ frei bleiben soll, wodurch Observer oder getter/setter nicht wirklich in frage kommen =/
Im Moment habe ich als Übergangslösung das ich alle Optionen direkt behandle, aber das ist ein Haufen ziemlich redundanter Code und das wollte ich jetzt irgendwie ändern.

 

[Schandro]

du könntest die Strings in einer Containerklasse zusammenfassen.

 

[Landei]

... oder in einem Array. Alter Standardtrick - die Notwendigkeit dafür deutet aber (wie schon von meinen Vorrednern ausgeführt) auf einen Designfehler hin.

void f(String s){ s = "Good bye "; }
String s = "Hallo ";
f(s);
System.out.println(s + "world"); //-> Hallo world

void g(String[] s){ s[0] = "Good bye "; }
String[] t = new String[]{"Hallo "};
g(t);
System.out.println(t[0] + "world"); //-> Good bye world

 

[SchonWiederFred]

Da Strings ja Objekte sind, sollte sie per Referenz übergeben werden.

Wie kommst Du darauf? Übergabe per Referenz existiert in Java nicht. Sowohl primitive Datentypen als auch Referenzdatentypen werden per Wert übergeben.

 

[Schandro]

Ja, der "Wert der Referenz" wird übergeben. Das heisst es gibt immer nur ein dahinterliegendes Object aber mehrere Referenzen die dadrauf zeigen. Deswegen hat der TO schon recht, jenachdem wie mans sieht.

 

[ARadauer]

ich bin absolut schandros meinung, die Strings ein einer Container Klasse verpacken... das mit den arrays würde ich nicht machen...