Zugriff mittels getObject() oder this.object ?

[-frank]

ich habe eine kleine designfrage zu folgendem beispiel-code:

class A {

    private Object field1;
    protected Object field2;

    public Object getField1() ..
    
    public Object getField2() ..

    void doSomething1() {
    ..
    System.out.println(" ... " + getField1());
    System.out.println(" ... " + this.field1);

    }
}

Class B extends A {
    void doSomething2() {
    ..
    System.out.println(" ... " + getField2());
    System.out.println(" ... " + this.field2);

    }
}

es geht um die zugriffe auf die felder. ich bin mir oft nicht sicher, ob ich mittels get() oder direkt auf die felder zugreifen soll. gibt es zb eine sicherheitsabfrage wie hier:

Object getField1() {
    if(isInitialized()) {
        return Field1;
    }
    else throw new Exception...
}

dann kann ich von fall zu fall entscheiden, ob ich die sicherheitsabfrage auch bei zugriffen innerhalb des objekts benötige oder nicht. bei mir ist es aber öfters so, dass es diese abfragen zunächst nicht gibt, aber diese schon kommen könnten (okay, eventuell sollte ich hier besser vorausplanen...).
oder zb folgende situation:

String getData() {
    return this.data;
}

wird zu:

String getData() {
    return this.data1 + ", " + data2;
}

hier wäre es natürlich angenehmer, wenn man im code überall die get()-Methode stehen hat statt eines direkten zugriffs. umgekehrt ist der direkte zugriff wohl schneller. (oder kann dies der compiler wegoptimieren? (wenn ja, nur innerhalb der klasse oder auch bei der abgeleiteten klasse?)

sollte man generell direkt zugreifen und nur, wo es nötig ist bzw. wahrscheinlich mal nötig sein wird, mittels get(), oder ist es durchaus auch üblich mal vorsichtshalber mittels get zuzugreifen? würdet ihr es bei der abgeleiteten klasse so sehen, dass die protected variable ein zeichen des programmierers, dass man direkt zugreifen kann/soll? (denn wenn der entwickler damit rechnen würde, dass das feld eventuell verschwindet bzw. sich irgendwie ändert, dann würde er dieses ja private machen und get() und public/protected set() anbieten.)

in fremden code sehe ich meistens direkte zugriffe. ist dies im normalfall bzw. zweifelsfall die bessere wahl? [/code]

 

[SlaterB]

ob schneller oder nicht ist irrelevant wenn es um logischen/ nachvollziehbaren Code geht,
(u.a.) deswegen benutzt man ja Java und nicht Assembler oder anderes kryptisches was sicherlich schneller wäre,

schneller wäre vielleicht auch in Java ein einzelnen Objekt mit 10.000 Exemplarvariablen,
aber die ganze Objektauftrennung ist ja (u.a.) eine Strukturierung für den Leser,

so für mehr erzählen habe ich gerade keine Lust mehr,
kommen sicher noch andere

 

[schalentier]

Ich schliesse mich uneingeschraenkt meinem Vorposter an.

Nimm wann immer es geht die getter/setter-Methoden. Die Vorteile hast du ja bereits selber erkannt, den Nachteil mit der Geschwindigkeit kannst und solltest du einfach vergessen.

Falls deine Anwendung zu langsam wird, kannst du mittels eines Profilers die tatsaechlichen Bottlenecks finden und ausbessern. Aber ich denke, getter/setter-Aufrufe werden nicht bemerkenswert die Performance druecken...

Im uebrigen ist es tausend Mal besser, gut und angenehm lesbaren Code zu schreiben, der ein bisschen langsamer laeuft, dafuer aber funktioniert und wartbar ist, als auch noch das letzte Prozent Performance rauskitzeln zu wollen und dabei viele Codeconventions und einfache Mittel, lesbaren Code zu schreiben, zu vergessen (Genauso ist es im Deutschen auch, siehe den vorigen Satz. Ist viel drin, aber kaum lesbar ;-) ).

 

[sparrow]

Ich befürchte das kann man gar nicht so genau verallgemeinern.

Bei mir sieht es in der Regel so aus, dass ich getter und setter nur verwende wenn die entsprechende Variable "von aussen" veränderbar sein soll.
Geht es ausschließlich darum Objekte von der selben Klasse aus zu verwenden benutze ich den direkten Zugriff und stelle dem ganzen ein this. voran, da fände ich getter/setter eher hinderlich und unübersichtlich.

Gruß
Sparrow

 

[-frank]

der minimale performance gewinn spielt meist natürlich keine rolle. da ist ein lesbarerer sicher mehr wert (in den meisten fällen). also da verstehe ich euch voll.
interessant finde ich aber, dass ihr anscheinend beide der meinung seid, dass get/set eindeutig lesbarer ist als der direkte zugriff. für mich ist dies nicht so eindeutig, da ich bei

...
Object obj = getObject();
..

auf den ersten blick nicht weiß, ob die get-Methode mehr macht als nur das objekt zurückzuliefern. bei

...
Object obj = this.object;
..

ist dies sofort ersichtlich.

aus den oben genannten gründen tendiere ich zur benutzung von getter/setter-methode auch innerhalb einer klasse. aber als lesbarer hätte ich eher den direkten zugriff gesehen. (--> zum selbst programmieren ist mir get() lieber, wenn ich in fremden code sehe, finde ich ein this.object eindeutiger, weil ich mir nicht die get()-methode ansehen muss)

würdet ihr dann so weit gehen private getter/setter methoden zu schreiben?

 

[Wildcard]

Grundsätzlich getter/setter zu verwenden is Designtechnisch günstiger da neue Funktionaliät flexibler durch überschreiben der getter hinzugefügt werden kann. Das macht allerdings nur sinn bei zumindest 'friendly' gettern, für private getter sehe ich keine sonderliche Notwendigkeit (es sei denn hier ist zusätzliche Logik erforderlicht).

 

[SlaterB]

intern ist es zum Teil egal, ja, was sollte sonst getX() machen

das ist hauptsächlich für extern gedacht,
aber auch für andere Logikteile in der eigenen Klasse oder gar in abgeleiteten Klassen,
wenn die Klasse so groß/ vielseitig wird, dass man schon von verschiedenen Teilen sprechen kann
(einer kümmert sich um die Verwaltung der Exemplarvariablen)

ob in diesem Fall die Klasse eh neustrukturiert werden sollte sei mal dahingestellt


wie gesagt ist eine abgeleitete Klasse meiner Meinung nach praktisch wie eine externe zu behandeln,
die Klassengrenze ist z.B. wegen Hervorhebung von Eclipse eine entscheidene Grenze beim Programmieren,
aber natürlich auch im konzeptionellen Sinne

-----

es geht aber auch andersrum,
wenn man reine Containerklassen für 10 unterschiedliche Variablen hat,
ohne jede weitere Funktionalität, ohne großen Transport sondern nur im Kontext von zwei/ drei Verarbeitungsklassen,
vielleicht gar nicht mal public deklariert/ interne Klasse,
dann kann man da sicher auch direkt drauf zugreifen,

nix für mich, mich persönlich würde allein schon die Schreibweise object.object stören,
auch this.x ist nicht so schön anzuschauen..,
allerdings benutzte ich dann Exemplarvariablen auch oft ganz ohne this oder getX(), sondern nur x

 

[-frank]

hmm, okay, dann gilt also:
1. getter/Setter methoden sind prinzipiell praktisch, wenn man den code später verändert. direkten zugriff von "außen" vermeiden (aber das ist mir eh klar, mir gings u.a. nur um die frage, ob eine abgeleitete klasse als "außen" gilt). ausnahme: public static final und sowas.
2. private getter/setter methoden sind übertrieben bzw. nicht nötig, solange da nicht mehr funktionalität drin steckt oder man davon ausgeht, dass diese funktionalität in zukunft benötigt werden wird.

dann noch 2 fragen:
1. public/"friendly" getter/setter existieren bereits für den zugriff von außen, müssen also nicht extra geschrieben werden. dann fügt man schnell mal ne methode dazu wie zb toString(). um das objekt zu beschreiben, braucht man zugriff auf ein paar variablen. wenn ihr nicht mehr informationen habt: public getter verwenden oder direkten zugriff?

2. protected variablen oder private variablen plus protected getter/setter? zumindest du, SlaterB, bist eher für letztere variante wenn ich das richtig verstanden habe oder?

 

[SlaterB]

jo,
und wenn es die getter gibt, dann wäre es bei Problemen (NullPointerException) für mich nervig, nach Variable UND nach getter zu setzen,
deshalb da auch in toString lieber getter benutzen,


allerdings oft mehr Vorsatz als wirklich praktikabel


nett ist auch zum Debuggen in einen getter
System.out.println(Aufruf durch, Wert = );
reinzuschreiben,
und vorallem ein setter ist dann viel leichter zu überwachen, als die 8 lokalen Stellen an denen die Exemplarvariable geändert wird