Welches Objekt ruft die Methode auf?

[Marcel_Handball]

Hallo zusammen,

ich habe eine generelle Frage. Folgendes Szenario:

class A{

   B objekc1 = new B();
   B object2 = new B();

   object1.ausführen();
}

class B{
   public void ausführen(){
   
      // hier möchte ich wissen, welches Objekt die Methode aufgerufen hat

   }
}

Wie kriege ich nun in der Methode heraus, welches Objekt die Funktion aufgerufen hat?
Bitte um Rat

Gruß Marcel

 

[Wildcard]

Warum möchtest du das wissen?

 

[Marco13]

this!?!

 

[Marcel_Handball]

Ich habe insgesamt 3 Klassen.

Person, Konto und Katze

public class Person
{
    private String name;
    private String telefon;
    private Konto konto;
    
    public Person(String name, String telefon)
    {
       this.name = name;
       this.telefon = telefon;
       konto = new Konto(Integer.parseInt(telefon),name);
    }

    public String getName()
    {
        return name;
    }
    
    public String getTelefon()
    {
        return telefon;
    }

    public Konto getKonto()
    {
        return konto;
    }
    
    public void katzeKaufen(){
        
    }
}

public class Konto{

    private int nummer;
    private String inhaber;
    private double kontoStand;

    public Konto(int nummer, String inhaber){
        this.nummer = nummer;
        this.inhaber = inhaber;
        kontoStand = 0;
    }    

    public double gibtKontoStand(){
        return kontoStand;
    }

    public void einzahlen(double einzahlung){
        kontoStand += einzahlung;
    }
    
    public void abheben(double auszahlung){
        kontoStand -= auszahlung;  
    }   
    
    public void ueberweisen(Konto empfaenger, double betrag){
        abheben(betrag);
        empfaenger.einzahlen(betrag);
    }
    
    public String gibInhaber(){
        return inhaber;
    }
    
    public int gibKontoNummer(){
        return nummer;
    }
      
}

Erstelle ich ein Objekt von Person, hat dieses Objekt sein eigenes Konto.

Person ich = new Person("name", "telefonnummer");

Nun möchte die Person eine Katze kaufen und ruft die Methode "kaufen" aus der Klasse Katze auf. Diese Methode muss nun aber wissen, von welchem Konto sie eine Geldsumme abrechnen soll.
Wüsste ich nun in dieser Methode das Personen-Objekt, welches die Methode aufgerufen hat, könnte ich schreiben:

Objektname.konto.abheben();

 

[SlaterB]

übergib die Person oder ihr Konto als Parameter an die Operation kaufen

 

[Marcel_Handball]

Klar, auf die einfachsten Sachen kommt man nicht.

Danke trotzdem!!

 

[Rock Lobster]

Das hat mich aber hin und wieder auch gestört... Java ist so krass "Reflection-mäßig" nutzbar, da wäre es manchmal echt wünschenswert, in jeder Methode auf den Caller und auch auf dessen Methode zuzugreifen. Habe im Moment ein Projekt, wo ich relativ oft als Parameter den Caller übergebe, aber auf Dauert nervt das, und ich bin mir sicher, daß es vielen anderen genauso geht.

Ich glaube auch, daß sprachlich schon relativ viel gegeben ist, sodaß durch diese Zusatzfunktionalität kaum mehr Overhead entstehen könnte. Ich mein, die Stack-Traces kommen ja auch nicht von ungefähr, und auf deren Basis dürfte es doch eigentlich technisch gar kein Problem sein, z.B. ein "caller"-Keyword einzuführen (so wie "this" und "super"), von dem man die class und die Methode getten kann.

Sollte man vielleicht mal bei Sun in die "Vorschlagbox" werfen

 

[SlaterB]

bei sowas ist aber ganz dicke die Gefahr der Verwahrlosung des Codes da,

this und super sind elementare Bestandteile der Objektorientierung,
in tausenden Büchern aufgeführt, in tausenden Sprachen enthalten,

einen caller zu gebrauchen steht ganz klar für schlechtes Design,
das brauchst du Java nicht vorschlagen

für eine Reflection- oder StackTrace-Lösung wäre ich aber auch,
als Strohhalm allein schon fürs Logging/ Debugging

 

[Rock Lobster]

Jo gerade das ist ja wichtig, wenn z.B. in einer Methode ein Fehler vermutet wird, dann wäre es manchmal sehr praktisch, sich über einen SysOut einfach den Caller auszugeben.

Aber Du hast Recht, natürlich entspricht das nicht den gängigen Prinzipien. Als Keyword sollte das dann also nicht nötig sein

Ob allerdings Reflection da so viel besser ist? Hier kann ich über jede beliebige Klasse alles erfahren, und auch das ist denke ich mal nicht mit "streng hierarchischen" und "ich darf nix über dich wissen"-Regeln zu vereinbaren

Von daher wäre es wohl echt nicht schlecht, wenn es zwar kein Keyword wäre, aber es zumindest über ein paar Umwege dennoch möglich wäre... (obwohl ich's dann nicht nur zum Debuggen nutzen würde )

 

[Guest]

bei sowas ist aber ganz dicke die Gefahr der Verwahrlosung des Codes da,

this und super sind elementare Bestandteile der Objektorientierung,
in tausenden Büchern aufgeführt, in tausenden Sprachen enthalten,

einen caller zu gebrauchen steht ganz klar für schlechtes Design,

Wieso? Über Reflection komm ich doch eh an alles ran, da wäre die caller-Lösung doch sauberer, oder?
(Bitte nicht anmaulen, erkklären, ich wills ja verstehen)

 

[Rock Lobster]

Naja, es werden bei OOP ja i.d.R. strenge Hierarchien gepredigt. Ein Auto sollte wissen, was es für 'nen Motor drin hat, aber der Motor sollte nicht wissen, in welchem Auto er steckt, bzw. daß er überhaupt in einem Auto steckt. Wenn nun das Auto den Motor startet, soll er das einfach machen "und sein Maul halten". Er hat quasi nix zu sagen

Wenn nun aber der Motor rauskriegt, wer ihn aufruft, dann ist er viel zu mächtig. Er könnte sagen "Was?! Ich bin in einem Ford Ka? Oh nein! Ich verweigere jetzt meinen Dienst"

Natürlich gibt es Fälle, wo es praktisch wäre, über den Caller bescheid zu wissen, aber SlaterB hat Recht - wenn das zum Standard-Feature wird, dann benutzt das jeder immer und überall, einfach aus Bequemlichkeitsgründen, und denkt nicht mehr über eine saubere Strukturierung des Codes nach. Zumindest wird das bei einigen Leuten so sein. Sprich, das Feature wird öfter genutzt, als es eigentlich nötig wäre, und es ersetzt für manche wohl die Planung einer sauberen Architektur. Hat im Grunde was von "globalen Variablen". Die sind bequem und einfach und für Anfänger meist "straight forward", aber wenn man ersteinmal Ahnung von guter Architektur hat, dann kann man super ohne globale Variablen auskommen und sieht auch sämtliche Vorteile (bzw eben die Nachteile der globalen Variablen).

So gesehen ist es also richtig, daß das kein Standard-Feature sein sollte. Reflection ist in den meisten Fällen ebenfalls nicht nötig, und es ist etwas, was noch einigermaßen umständlich zu bedienen ist. Gäbe es jetzt direkte, bequeme Reflection-Keywords, dann würde dies auch viel öfter falsch eingesetzt werden. So bleibt es aber nur den Fällen vorbehalten, wo es wirklich nötig ist, und meist können die Programmierer dann auch damit umgehen.

 

[Rock Lobster]

Über Reflection komm ich doch eh an alles ran, da wäre die caller-Lösung doch sauberer, oder?

Das ist auch nicht ganz korrekt - im Moment kann man die Reflection-API nicht so einsetzen, wie wir es gerade besprechen. Man kann alles über eine Klasse erfahren, aber man kann nicht zur Laufzeit innerhalb einer Methode herauskriegen, wer einen da gerade aufgerufen hat (zumindest wäre mir hierfür keine Möglichkeit bekannt).

 

[SlaterB]

Wieso? Über Reflection komm ich doch eh an alles ran, da wäre die caller-Lösung doch sauberer, oder?
(Bitte nicht anmaulen, erkklären, ich wills ja verstehen)

wie gesagt: über Reflaction, damit wäre ich einverstanden, aber kein direktes caller-Objekt

wobei Reflection für sowas auch gar nicht da ist, es is eher der StackTrace gemeint,
mit Reflection meine ich nur 'auf irgendeine Umweg-API'