[JAVA] Methodenaufrufe

[madbros]

Mahlzeit,

gibt's ne Möglichkeit, den Namen einer aufrufenden Methode herauszubekommen. Für Klassen geht das, das weiss ich, aber für Methoden?

so in der Art:

class testklasse {

   static void methode1() {

      methode(2);

   }

}

class testklasse2{
   
   static void methode 2() {

      wenn aufrufer = methode1 {

         machwas;

      } else {

         machwasanderes()

      }

   }

}

Danke

 

[KipDotter]

Hi!

Java 1.5 ?
Also die Holzhammer Methode wäre: Sich den Stacktrace zu holen, und nachzusehen, was die aufzurufende Methode war. Ist nicht wirklich schnell (und eigentlich auch wirklich unschln, aber wenn's hilft! )
Unter 1.5 ist das - glaube ich zumindest - etwas eleganter. Mit 1.4 müsstest du dazu eine Exception anlegen und raisen...

Tschau
Kip

Edit Java 1.5 Beispiel:
Beispiel: Finde heraus, in welcher Methode wir gerade stehen:
StackTraceElement e = Thread.currentThread().getStackTrace()[2];
System.out.println( e.getMethodName() );
(ich kanns leider nicht ausprobieren, aber wenn du die [2] durch eine [3] ersetzt, müsste dass dann die aufrufende Methode sein !)

 

[SheepShaver]

Selbst wenn das möglich ist, dann wäre das ein grauenhafter Programmierstil. Wer soll da bitteschön dann noch durchblicken? Wozu brauchst das überhaupt? Wenn Du unbedingt zusätzliche Infos über den Aufrufer brauchst, dann regl das lieber über ein Flag.

 

[madbros]

Das ist für eine Uni-Aufgabe. Die haben da was ganz abgefahrenes konstruiert, was es unmöglich macht, direkt auf die Inhalte eines Listenelementes (Name, Geburtsdatum) zuzugreifen. Stattdessen muss man das Ding in einen String umwandeln und dann mittels StringTokenizer wieder auseinanderknöpern, um sich die Elemente zu filtern und dann einen neuen String draus zu machen...

Einfacher wäre es, wenn die überschriebene toString() eine Unterscheidung zwischen den aufrufenden Methoden machen könnte und dann den passenden String zurücklieferte.

War also nicht meine Idee... :-)


Aber danke für die Tips

 

[Green Mamba]

Warum nicht einfach der Methode2 einen Paramter (z.B. eine Enumeration) übergeben, wodurch ersichtlich ist, wer der Aufrufende ist.

Also statt

 methode2();

einfach so was in der Art:

 methode2(METHODE1);

 

[madbros]

weil wir zwingend toString() (die also die Methode2 ist) überschreiben sollen... und die hat nunmal leider keine Parameter...

 

[lynxx]

Entweder hat Dein Prof. keinen Schimmer oder Du hast es nicht richtig verstanden.

Postet doch mal genau die Aufgabe und/oder den Vorgabecode.

 

[Arnd]

Dann bastel doch einfach in den String die aufrufende Methode mit rein.

Den Stack zu analysieren, widerspricht wohl jedem Grundsatz bzgl. Portabilität.

MfG

Arnd

 

[KipDotter]

@Arnd: Bitte nicht falsch verstehen. Ich weiss, dass mein Vorschlag mit dem Stacktrace grässlich ist, und auch weit jenseits eines guten Programmierstils ist, aber - und die Frage würde mich jetzt schon mal interessieren: Warum ist das gegen die Portabilität ? Ein Stacktrace ist ein Stacktrace, egal auf welchem BS.

Tschau
Kip

 

[Arnd]

Wie der Stack aufgebaut ist entscheidet doch wohl die Kombination von Compiler/Interpreter und CPU Architektur. Ich halte den Stack für abhängig von dieser Kombination. D.h. wenn sich an dieser Kombination etwas ändert, würde der Code nicht mehr funktionieren.
Angenommen der Code läuft auf einem Mac, oder die nächste Java Version ändert etwas an dem Layout, oder der Code wird auf einen andere Sprache (C++, ...) portiert.

Z.B. bei C oder C++ gibt es unterschiedliche Konventionen wie die Parameter eines Methodenaufrufs auf dem Stack abgelegt werden.

Wenn dann solche Konstrukte vorhanden sind, wird das ziemlich aufwendig das auf einer anderen Umgebung zum laufen zu bekommen.

Von daher sind Manipulationen am Stack etwas sehr spezielles und eher nicht portabel.
Ich lasse mich aber gerne eines besseren belehren :-).

Mit Java kenne ich mich nicht so besonders aus. Wenn Java den Stack komplett kapselt ok. Dann ist es in Java nur noch unschön. Aber der Code bleibt dann auf jeden Fall in der Java Welt gefangen :-).

MfG

Arnd

 

[Green Mamba]

Ja, ist sozusagen gekapselt, da Java-Programme generell auf einer VM laufen.
Und natürlich bleibt Java-Code in der Java-Welt gefangen, es ist ja nunmal Java-Code.

 

[madbros]

die Aufgabe gibt es hier.

meine Lösung kann ich nicht posten, das gab schon mal Ärger... könnte ja jemand abschreiben
Bin aber gern bereit, den Code jemand einelnem zu schicken.

Die Frage wäre jetzt: wie kann ich die methode writeExit() der Klasse EntryList so gestalten, dass sie (evtl. mittels einer zusätzlichen Methode in der Klasse Entry oder sonstwo) direkt auf die Komponenten name, tag, monat und jahr des ListItems bzw. des Entrys zugreifen kann.

Mit dem Stacktrace habe ich es jetzt so hinbekommen, dass ich den String, der mit it.toString() entsteht, nicht mehr zerpflücken und dann wieder zusammenfügen muss, sondern gleich den richtigen Ergebnisstring zurückbekomme.

 

[stengbiegel]

Die Frage wäre jetzt: wie kann ich die methode writeExit() der Klasse EntryList so gestalten, dass sie (evtl. mittels einer zusätzlichen Methode in der Klasse Entry oder sonstwo) direkt auf die Komponenten name, tag, monat und jahr des ListItems bzw. des Entrys zugreifen kann.

Indem du in Entry die entsprechenden Getter implementierst.

Mit dem Stacktrace habe ich es jetzt so hinbekommen, dass ich den String, der mit it.toString() entsteht, nicht mehr zerpflücken und dann wieder zusammenfügen muss, sondern gleich den richtigen Ergebnisstring zurückbekomme.

Nachdem ich die Aufgabe gelesen habe frage ich mich, wozu das überhaupt brauchst?
Nicht ohne Grund hat dein Tutor da einen Smiley hingesetzt.

Gruß,
stengbiegel

 

[madbros]

Indem du in Entry die entsprechenden Getter implementierst.

Bitte höflichst um Details... was sind Getter? und wie gehen Getter? waren in der Vorlesung noch nicht dran.... oder doch? Hilf mir mal bitte.

 

[lynxx]

Der Sinn der Sache ist die Vererbung zu nutzen, also mal als Beispiel:

class Entry extends ListItem {
      String name;           
      int tag;
      int monat;
      int jahr;

public Entry(String n, int t, int m, int j){ /* merke n und Geburtsdatum bestehend aus t,m und j und trage dieses ListItem in die Liste ein */ }

public String toString() {return name+" hat am "+tag+"."+monat+"."+jahr+" Geburtstag";}

//Getter-Methoden
public String getName() {return name;}
public String getTag() {return tag;}
public String getMonat() {return monat;}
public String getJahr() {return jahr;}

}
// Entry.java ---------------------------------------------------------------------------------------------------- 

...
ListItem liCurrent = myEntryList.first();
if (liCurrent instanceof Entry) { // Prüfen ob die richtige Klasse
 Entry myEntry = (Entry)liCurrent; // Casten nach Entry
 String strName = myEntry.getName(); // Getter Aufrufen
 ...
}
else {
 // Fehlerbehandlung - Unbekannte Klasse
}

 

[madbros]

ja, so schlau war ich auch...

folgendes Problem: non-static method getName() cannot be referenced from a static context...

weiss da jemand eine Lösung für? writeExit non-static zu machen geht nicht...

 

[lynxx]

ja, so schlau war ich auch...

folgendes Problem: non-static method getName() cannot be referenced from a static context...

weiss da jemand eine Lösung für? writeExit non-static zu machen geht nicht...

Du darfst ja auch nicht direkt auf Entry.getName() zugreifen, sondern musst dafür die Instanzen verwenden, also die angelegten Entry in der EntryList.

 

[stengbiegel]

Hi Madbros,
ging es in deinem Kurs nicht um Objektorientierung? Vielleicht ziehst du dir nochmal was zum Thema OOP, Vererbung etc. rein. Dann solltest du einiges in Bezug auf die Aufgabenstellung klarer sehen.

Übrigens, ein Getter ist eine Methode, die den lesenden Zugriff auf ein geschütztes Attribut einer Klasse erlaubt, der Setter ist das schreibende Gegenstück dazu. Siehe JavaBeans.

Gruß,
stengbiegel

 

[madbros]

als ich das Beispiel da oben gesehen habe, ist mir so einiges noch mal klar geworden.
Vorher hat es zwar auch funktioniert, aber so ist es deutlich besser und vor allem viel einfacher.

Danke.

 

[Helios co.]

Hallo,

wenn ich mich nicht irre, kann Java doch REFLEKTION..

Damit kann man auf Methoden (Programme) während der Laufzeit zugreifen und auch somit auch erfahren um welche Methode es sich handelt...

Hat was mit junit (Testing) zutun...