[Java] Ermitteln, welches Objekt eine Methode aufrief

[chrisyou]

Hallo!

Mein Code:

private void createComponents() {
	// TODO Auto-generated method stub
	txtRate = new JTextField();
	txtOwn = new JTextField();
        txtForeign = new JTextField();
        btnStart = new JButton(localize());
	createLayout();
}	
private String localize() {
	// TODO Auto-generated method stub
	return null;
}

Ich möchte:

• per "localize(X)" den Urheber des Methodenaufrufs übermitteln..
• Und anschließend den Text des JButtons als String zurückgeben (aus localize(X))

localize(this.btnStart) hat nicht funktioniert, daher suche ich Hilfe, wie ich das Objekt übergeben kann..

[dowhile]

Hi,

an localize() kannst du kein JButton-Objekt übergeben, da du in der Signatur keine Parameter angegeben hast. (Meinst du das?) Den Text vom JButton bekommst du mit JButton.getText().

[chrisyou]

Originally Posted by dowhile

Hi,

an localize() kannst du kein JButton-Objekt übergeben, da du in der Signatur keine Parameter angegeben hast. (Meinst du das?) Den Text vom JButton bekommst du mit JButton.getText().

Ich möchte ja nicht nur JButtons übergeben, sondern z.B. auch JLabel.
localize(JObject obj) scheint nicht zu funktionieren..

Den Text gebe ich ja als String an den Kontruktor des Objekts zurück.

Edit: Nvm, geht es vielleicht nicht, weil das Objekt selbst (der JButton) an der Stelle noch gar nicht exisitert bzw. noch konstruiert wird?

[dowhile]

Achso, jetzt verstehe ich das. Das geht nicht, denn wenn du den Konstruktor aufrufst, hast du schließlich noch gar kein Objekt.
Du kannst statt dem Objekt aber irgendeinen String (int) übergeben, der dein Objekt eindeutig identifiziert, und localize kann dazu den passenden String zurückgeben. So macht das zum Beispiel auch Android (dort: resources.getString(R.strings.XYZ)).

Oder du legst das Objekt zu erst an und nutzt dann setText(): btnStart.setText(localize(btnStart));
Du hast dann aber keine Möglichkeit, zwischen verschiedenen JComponent-Objekten zu unterscheiden. Also doch lieber wie oben (oder ganz anders).

[chrisyou]

Originally Posted by dowhile

Achso, jetzt verstehe ich das. Das geht nicht, denn wenn du den Konstruktor aufrufst, hast du schließlich noch gar kein Objekt.
Du kannst statt dem Objekt aber irgendeinen String (int) übergeben, der dein Objekt eindeutig identifiziert, und localize kann dazu den passenden String zurückgeben. So macht das zum Beispiel auch Android (dort: resources.getString(R.strings.XYZ)).

Oder du legst das Objekt zu erst an und nutzt dann setText(): btnStart.setText(localize(btnStart));
Du hast dann aber keine Möglichkeit, zwischen verschiedenen JComponent-Objekten zu unterscheiden. Also doch lieber wie oben (oder ganz anders).

Danke, ist mir auch eben aufgefallen.
Werde mir die Methode mal ansehen, habe jetzt aber erstmal alle Objekte erstellt und starte anschließend localize().
So findet auch nur eine Operation statt, statt viele (bei jedem Objekt).

Grüße

[Mikesch01]

Hab mir die Texte nun mehrfach durchgelesen und habe noch immer keine Ahnung, was du da eigentlich vor hast

Vielleicht hilft dir das weiter:
- du kannst die eigene Klasse mittels "this" weitergeben
- du kannst Objekte jeder Art mit einem Parameter vom Typ "Object" übergeben, auch wenn sie die spezifischen Klassenattribute und -methoden verlieren.

Kannst du genauer erläutern, was du denn vor hast?

[VisionEP1]

erweitere doch die Klassen der Objekte um eine funktion localize erweitern

[XxharCs]

Du kannst das Decorator -oder Factory-Pattern anwenden, dies sollte dein Problem um großes reduzieren.

[Mostey]

Originally Posted by XxharCs

Du kannst das Decorator -oder Factory-Pattern anwenden, dies sollte dein Problem um großes reduzieren.

Wieso sollten Patterns wie das Factory pattern hier die Lösung sein? Es geht sehr wohl ohne - man nutzt solche Prinzipien nur wenn man sie auch wirklich braucht, selbes Spiel wie bei Singletons.

[XxharCs]

Originally Posted by Mostey

Wieso sollten Patterns wie das Factory pattern hier die Lösung sein? Es geht sehr wohl ohne - , selbes Spiel wie bei Singletons.

Nur das das Singleton hier wenig bis garnichts bringen würde.
Wieso ich das Factory oder Decorator Pattern empfehle?

Ganz einfach, zur Zeit der Erstellung weiß er nicht welches Objekt er bekommen wird, nur zur Laufzeit wird er wissen welches Objekt da angesprochen werden soll. Mit Factory oder Decorator kann er sein Problem ganz leicht lösen können.

Originally Posted by Mostey

man nutzt solche Prinzipien nur wenn man sie auch wirklich braucht

Die Prinzipien bzw. Patterns sind da, um einem Programmierer das Leben leicht zu machen, beim programmieren selbst als auch später in der Zukunft wenn man den Code warten will usw. Man muss sie nicht anwenden, sollte man aber, wie schon im vorherigen Satz erläutert wieso. Manche Patterns sind irgendwo unnötig, manche aber widerrum nicht, kommt auf den Anwendungsbereich an.

Stell dir vor er will das bei vielen Components machen, am Ende wird er cik tausend Klassen haben um sein Problem zu lösen. Mit dem Decorater zB wird er dies sehr klein halten können und wird beim hinzufuegen neuer Sachen kein Problem haben, weil er bestehenden Code nicht angreift, keinen Gulasch aus Klassen haben wird usw.

[Mostey]

Originally Posted by XxharCs

Nur das das Singleton hier wenig bis garnichts bringen würde.

Und genau das hat niemand behauptet. Meine Aussage bezog sich darauf das viele Leute das Singleton Pattern nutzen, obwohl sie das entweder nicht müssen oder ihren Code unnötig gefährden.

Originally Posted by XxharCs

Wieso ich das Factory oder Decorator Pattern empfehle?

Ganz einfach, zur Zeit der Erstellung weiß er nicht welches Objekt er bekommen wird, nur zur Laufzeit wird er wissen welches Objekt da angesprochen werden soll. Mit Factory oder Decorator kann er sein Problem ganz leicht lösen können.

Woher nimmst du das? Er hat oben beschrieben dass es wohl ein Button oder Label sein wird. Und wenn es mehrere Elemente sein können, dann nimmt man eben die Überklasse (und die ist bei Java doch JObject, oder?)

Und das der Ansatz von ihm totaler Müll ist, UI bezogene Objekte an die Business layer zu übergeben, schafft nahezu unwartbaren Code aber das ist eine andere Geschichte.

Originally Posted by XxharCs

Die Prinzipien bzw. Patterns sind da, um einem Programmierer das Leben leicht zu machen, beim programmieren selbst als auch später in der Zukunft wenn man den Code warten will usw. Man muss sie nicht anwenden, sollte man aber, wie schon im vorherigen Satz erläutert wieso. Manche Patterns sind irgendwo unnötig, manche aber widerrum nicht, kommt auf den Anwendungsbereich an.

Wieso sollte man? Es gibt eine Grundregel bei diesen Patterns: Nutze sie, wenn du sie brauchst. Wenn du sie nicht brauchst, nutze sie auch nicht. Das hat nicht umsonst Gründe. Ich kenne dieses Decorator Pattern zum Beispiel überhaupt nicht. Wieso soll ich eigentlich lernen wie dieses Pattern funktioniert obwohl es nicht unbedingt benötigt wird? Ich meine - wo ist der Vorteil gegenüber einer Basisklasse die du einfach in den Methoden voraussetzt?

Wieso soll ich meinen Scope mit Singleton Klassen verschmutzen die am Ende eigentlich gar nicht unbedingt nach dem Singleton Prinzip funktionieren müssen?

Originally Posted by XxharCs

Stell dir vor er will das bei vielen Components machen, am Ende wird er cik tausend Klassen haben um sein Problem zu lösen. Mit dem Decorater zB wird er dies sehr klein halten können und wird beim hinzufuegen neuer Sachen kein Problem haben, weil er bestehenden Code nicht angreift, keinen Gulasch aus Klassen haben wird usw.

Wieso sollte man überhaupt Komponente die zum UI gehören nach unten geben wollen? Und wenn es so wäre, was hindert ihn (wie oben schon erwähnt) an einer Basisklasse oder einem Interface? Ich sehe den Fehler hier einfach nur im Design.

[MrSm!th]

Und das der Ansatz von ihm totaler Müll ist, UI bezogene Objekte an die Business layer zu übergeben, schafft nahezu unwartbaren Code aber das ist eine andere Geschichte.

Lokalisierung ist keine Business Logic, sondern Oberflächenlogik, also ist das vollkommen legitim.
Das Factory Pattern ist hier dennoch völlig am Thema vorbei - es geht nicht um Objekterstellung, sondern um die Zuweisung von lokalisierten Strings zu bestimmten Controls.

Wieso sollte man? Es gibt eine Grundregel bei diesen Patterns: Nutze sie, wenn du sie brauchst. Wenn du sie nicht brauchst, nutze sie auch nicht. Das hat nicht umsonst Gründe. Ich kenne dieses Decorator Pattern zum Beispiel überhaupt nicht. Wieso soll ich eigentlich lernen wie dieses Pattern funktioniert obwohl es nicht unbedingt benötigt wird? Ich meine - wo ist der Vorteil gegenüber einer Basisklasse die du einfach in den Methoden voraussetzt?

Zwar ist es Unsinn auf Teufel komm raus Patterns in den Code klatschen zu wollen, aber deine Logik ist hier auch nicht wirklich schlüssig. Woher will ich wissen, ob mein Code durch ein Pattern verbessert werden könnte, wenn ich es gar nicht kenne? Die Frage "Warum sollte ich das lernen?" ist immer Schwachsinn, da zusätzliches Wissen niemals schadet.

[Mostey]

Originally Posted by MrSm!th

Lokalisierung ist keine Business Logic, sondern Oberflächenlogik, also ist das vollkommen legitim.

Wieso? Sobald du ein Buttonobjekt nach unten weitergibst, befindest du dich in der Business Layer und bist somit in der Interaktion zwischen UI und Daten. Ich bleibe dabei, es ist absolut unangebracht.

Originally Posted by MrSm!th

Das Factory Pattern ist hier dennoch völlig am Thema vorbei - es geht nicht um Objekterstellung, sondern um die Zuweisung von lokalisierten Strings zu bestimmten Controls.

Was natürlich auch sehr klar und deutlich vom TE formuliert wurde...

Originally Posted by MrSm!th

Zwar ist es Unsinn auf Teufel komm raus Patterns in den Code klatschen zu wollen, aber deine Logik ist hier auch nicht wirklich schlüssig. Woher will ich wissen, ob mein Code durch ein Pattern verbessert werden könnte, wenn ich es gar nicht kenne?

Ich habe nicht gesagt das ich es nicht kenne, ich weiß sehr wohl was Sinn und Zweck davon ist - nicht aber, wie man es vernünftig anwendet. Daher macht meine Logik schon irgendwo Sinn, meinst du nicht?

Originally Posted by MrSm!th

Die Frage "Warum sollte ich das lernen?" ist immer Schwachsinn, da zusätzliches Wissen niemals schadet.

Es kostet Zeit - Zeit die begrenzt ist. Nehmen wir als Beispiel doch mal ein Projekt in deiner Firma. Nun kam jemand auf die Idee, tausende von Patterns in deiner Lieblingssprache zu implementieren die nicht unbedingt benötigt wurden und durch einfache Konstrukte in der Sprache selbst ersetzt werden könnten. Du kennst ein Großteil dieser Patterns aber nicht - also hast du einen deutlichen Mehraufwand beim Verständnis wenn du den Code ändern musst. Und da kannst du mir erzählen was du willst, das betrifft ebenfalls so gut wie alle Frameworks.

Immer Schwachsinn? Alles klar...

[VisionEP1]

Auch wenn Mr. Unantastbar anderer Meinung ist,
die oben vorgeschlagene Lösung ist durchaus angebracht.
Moesty hat das meiste ja schon gesagt.
Zu welcher Lösung du greifst hängt nochmal von deinem Projekt ab,
Es gibt ja de fakto mehr als nur die perfekte Programmier argumentation
-Wartbarkeit(verwendungszweck)
-Zeitaufwand
-Größe des Projekts
Musst du abwägen und kannst so zum richtigen Schluss kommen

[MrSm!th]

Wieso? Sobald du ein Buttonobjekt nach unten weitergibst, befindest du dich in der Business Layer und bist somit in der Interaktion zwischen UI und Daten. Ich bleibe dabei, es ist absolut unangebracht.

Nein, Lokalisierung ist Oberflächenlogik und keine direkte Geschäftslogik.

Was natürlich auch sehr klar und deutlich vom TE formuliert wurde...

Mindestens zwei haben es verstanden, aber da hast du nicht Unrecht.

Ich habe nicht gesagt das ich es nicht kenne

->

Ich kenne dieses Decorator Pattern zum Beispiel überhaupt nicht

Aha?

ich weiß sehr wohl was Sinn und Zweck davon ist - nicht aber, wie man es vernünftig anwendet. Daher macht meine Logik schon irgendwo Sinn, meinst du nicht?

Nein, das ändert nicht wirklich etwas am Sachverhalt. Wenn man eine Wissenslücke hat, sollte man sie füllen und nicht sagen, dass es eh unnötig ist.
Es gäbe das Pattern nicht, wenn es sich nicht vernünfig anwenden ließe.

Es kostet Zeit - Zeit die begrenzt ist. Nehmen wir als Beispiel doch mal ein Projekt in deiner Firma. Nun kam jemand auf die Idee, tausende von Patterns in deiner Lieblingssprache zu implementieren die nicht unbedingt benötigt wurden

Ab hier wird das Beispiel schwachsinnig und zeigt, dass du den Kern des Problems nicht erkannt hast. Ich habe ganz klar und deutlich gesagt, dass es nicht darum geht, den Code mit Patterns vollzukleistern. Ich sagte, dass es nie schaden kann, möglichst viele zu kennen. Erst durch ein solides Grundwissen kann man auch in der Praxis effizient arbeiten. Patterns sind letztendlich nichts anderes als Muster von Lösungen, die Entwickler vor dir auf immer wieder vorkommende Probleme gefunden haben. Es sind Schablonen, die sich für diese Arten von Problemen sehr gut durchgesetzt haben. Diese zu kennen ist immer sinnvoll, um das Rad nicht ständig neu zu erfinden. Nicht umsonst gibt es ganze Studiengänge alleine über die Architektur von Software. Das ist einer der Unterschiede zwischen einem Entwickler und einem Code Monkey.

Übrigens: Wenn man ein Pattern nicht kennt, ist der Code nicht direkt unverständlich, im Gegenteil. Patterns helfen, die teils komplexen Lösungen und Gedankengänge dahinter in ein gemeinsames Vokabular zu fassen. Leute, die sie nicht kennen, haben davon dann zwar keinen Mehrwert, aber auch keinen Schaden, denn ohne Pattern wäre das Vokabular genau so wenig da.