Setter/Getter für Instanzvariablen praktisch?

[Dibelius]

Back to basics...

Gibt es in Java einen praktischeren Weg für Getter und Setter, als der klassiche Umweg über Methodenaufrufe? Mich stören oft die vielen Klammern, weshalb der Code schnell mal unleserlich wird.

class Test
{
   private int count

   public void setCount(int v) {
      this.count = (v >= 0) ? v : 0;
   }

   public int getCount() {
      return this.count;
   }
}

// Aufruf aus anderer Klasse
   int newCount = testinstanz.getCount();
   testinstanz.setCount(10);

In ActionScript (und vielleicht auch in einigen anderen Script-/Programmiersprachen) gab es dafür eine elegante Lösung mittels spezieller Getter- und Setter-Methoden:

   private var count :int;
   public function set count(v:int):void { ... }
   public function get count():int { ... }

// Aufruf aus anderer Klasse
   int newCount = testinstanz.count; // getter
   testinstanz.count = 10; // setter

Mir gefällt bei diesem Ansatz die Klarheit. Das private Feld bleibt privat und somit geschützt, der eigentliche Zugriff erfolgt über die speziellen Methoden. Insbesondere beim Setter finde ich die Syntax sehr angenehm mittels Zuweisungsoperator.

 

[Xyz1]

als der klassiche Umweg über Methodenaufrufe

Nein

die vielen Klammern, weshalb der Code schnell mal unleserlich wird

und Nein, insbesondere Klammern erhöhen die Lesbarkeit

In ActionScript

Java ist NICHT JavaScript....

die Klarheit

welche Klarheit?

schönen Abend noch.

 

[temi]

Gibt es in Java einen praktischeren Weg für Getter und Setter, als der klassiche Umweg über Methodenaufrufe?

Nicht das ich wüsste. Getter und Setter sind der richtige Weg, sollten aber dennoch (insbesondere Setter) sparsam eingesetzt werden, weil sie eine direkte Veränderung des Objektzustands ermöglichen. Das ist meist nicht erwünscht. Eine Klasse sollte soviel Information verbergen, wie möglich.
Zustandsänderungen erfolgen i.d.R. über eine Aktion im Zusammenhang mit dem Objekt. Bei einem Feld "count" wäre z.B. denkbar, dass der Zähler inkrementiert wird, wenn eine Aktion "add(...)" durchgeführt wird und dekrementiert wird bei "remove(...)".

 

[L0oNY]

Hi,

wäre das vielleicht etwas was du suchst?
https://projectlombok.org/

 

[Dibelius]

Danke an #3 und #4

Mein bescheidenes Ziel ist eigentlich nur, einem potentiellen Anwender meiner Hauptklasse eine bequeme Instanz-Manipulation zu ermöglichen, wo es sinnvoll erscheint.

MainClass main = new MainClass();
main.array = new int[]{1,2,3};
main.amount = 3;
main.doSomethingWithCurrentValues();

Das Feld 'count' war nicht das beste Beispiel. Konkret müsste es 'amount' heißen, weil ich eine Anzahl an Schleifendurchläufen festlegen möchte. Das kann/möchte ich weder im Konstruktor tun, noch bei der letzten Methode als Argument mitliefern. An der Stelle denke ich vielleicht noch zu wenig in JAVA, und mir ist klar, dass wenig dafür sprechen mag, die nötigen Argumente nicht direkt mitzuliefern, dort, wo sie benötigt werden. Es gibt ja einen Standardwert, womit gearbeitet wird, wenn nicht explizit der 'amount'-Wert überschrieben wird. Aus dem Grund möchte ich auch den Methodenaufruf nicht von vornherein mit Parametern überfrachten (und auch überladene Methoden sparsam einsetzen).

Lange Rede, kurzer Sinn:
Ich habe es jetzt für mich so gelöst, dass ich den Zugriff, wie im oberen Beispiel direkt mit public-Feldern gestatte und der Verwender der Klasse erst einmal alles mögliche angeben kann. Die Validierung, ob der Wert tatsächlich sinnvoll ist, erfolgt dann in der oder den Methoden, wo die Variable zum Einsatz kommt an Ort und Stelle. Ein simples Beispiel:

package x.y.z

public class MainClass
{
   int amount = 5;

   public void doSomethingWithCurrentValues() {
      // Wert mit lokaler Methode bereinigen
      this.validateAmount(this.amount);

      // paket-internes Verwaltungsobjekt für klassenübergreifende Verwendung
      packageDataObject.validateAmount(this.amount);
   }

   private void validateAmount(int value) {
      this.amount = value < 0 ? 0 : (value > 10 ? 10 : value);
   }
}

package x.y.z

class PackageData
{
   int amount; // in anderen Paket-Klassen wird nur mit diesem Wert gearbeitet

   void validateAmount(int value) {
      this.amount = value < 0 ? 0 : (value > 10 ? 10 : value);
   }
}

Das ist sicher etwas umständlich gedacht, aber mir sind die Manipulation und der Zugriff so lieber.
Nur für den Getter habe ich keine passende Lösung anzubieten, wobei mir das für die paketinterne Verwendung weniger wichtig ist.

 

[Xyz1]

Ich habe es jetzt für mich so gelöst, dass ich den Zugriff, wie im oberen Beispiel direkt mit public-Feldern gestatte

Ehrlich gesagt ist das noch unsinniger als Deine ursprüngliche Frage

Ist so in etwa: Wie wichtig ist dieses tragende Element (für die Statik der Decke)? Sehr wichtig. Dann lasse ich es weg

 

[Dibelius]

Es funktioniert und vereinfacht die Verwendung der Hauptklasse.
Darum ging es mir.
Ob sinnvoll oder nicht... worin genau liegt Dein Problem mit meinem Lösungsansatz?

Ich zitiere:
"schönen Abend noch."

 

[Xyz1]

worin genau liegt Dein Problem mit meinem Lösungsansatz

Weil es kein Lösungsansatz ist.

 

[Goldi]

Der Grund warum Setter unverzichtbar und eine klasse Lösung sind ist ganz einfach: In einen 12-Liter-Wasserkübel passen nun mal keine 25 Liter Wasser (siehe nachfolgender Code). Es geht um Typsicherheit, Konsistenz, Ausschalten von Fehlerquellen bei der Verwendung Deiner Klasse mit public-Eigentschaften. Ich finde es weniger umständlich, mehr genial und top leserlich - letzteres ist dann wohl Geschmackssache. Bei der professionellen Programmierung (wo oft mehrere beteiligt sind) geht's aber viel mehr um einheitliche Sprachkonventionen als um Geschmack. Hier der Wasserkübel zur Veranschaulichung von Fehlerquellen:

public class Wasserkuebel {
   
    // Das Fassungsvermögen eines Wasserkübels defniert sich aus Radius bzw.
    // Durchmesser und Höhe. Der Radius ist fest vorgegeben, die Höhe verstellbar:
   
    public final double radius = 20.0;   // Radius = 20 cm
    public double hoehe;
    private double wassermenge = 0.0;     // Wassermenge im Kübel in Liter
   
    /** @param hoehe Küble-Höhe in cm */
    public Wasserkuebel(double hoehe) {
        this.hoehe = hoehe;
    }
   
    public double getVolumenLiter() {
        return Math.PI * radius * radius * hoehe / 1000.0;
    }
   
    public void fuelleWasserEin(double liter) {
        liter = liter < 0.0 ? 0.0 : liter;
        if (wassermenge + liter > getVolumenLiter()) {
            wassermenge = getVolumenLiter();    // Mehr passt nicht rein.
        } else {
            wassermenge += liter;
        }
    }
   
    /** Höhe wird neu gesetzt.
     * @param hoehe Neue Höhe des Wasserkübels in cm*/
    public void setHoehe(double hoehe) {
        this.hoehe = hoehe;
        if (wassermenge > getVolumenLiter()) {
            // Bei einer Verkleinerung wird u. U. Wasser verschüttet:
            wassermenge = getVolumenLiter();
        }
    }
   
    public void aktuellerStand() {
        System.out.println("Wasserkübel: Fassungsvermögen=" + getVolumenLiter()
            + " l, enthaltene Wassermenge=" + wassermenge + " l");
    }
   
    public static void main(String[] args) {
        Wasserkuebel kuebel = new Wasserkuebel(40d);
        kuebel.fuelleWasserEin(50.0);
       
        // Unterschied von Setter ...
        kuebel.setHoehe(20.0);
        kuebel.aktuellerStand();
            // Ausgabe:
            // Wasserkübel: Fassungsvermögen=25.13274122871835 l, enthaltene Wassermenge=25.13274122871835 l
           
        // ... und direkter Manipulation:
        kuebel.hoehe = 10.0;
        kuebel.aktuellerStand();
            // Ausgabe:
            // Wasserkübel: Fassungsvermögen=12.566370614359174 l, enthaltene Wassermenge=25.13274122871835 l
    }
}

 

[Meniskusschaden]

Es funktioniert und vereinfacht die Verwendung der Hauptklasse.

Eigentlich nicht, denn der Verwender wäre ja wohl ein Java-Programmierer und der erwartet natürlich Java-Konventionen - unabhängig davon, ob das nun grundsätzlich etwas besser oder etwas schlechter als das Konzept aus deinem Eröffnungsposting ist.

Der Direktzugriff ohne Methode ist in jedem Fall eine schlechte Wahl.

 

[Meniskusschaden]

Ob sinnvoll oder nicht... worin genau liegt Dein Problem mit meinem Lösungsansatz?

Noch ein paar Ergänzungen zum Beitrag von @Goldi: Die ganzen Prüfungen, die @Goldi vorgeschlagen hat, kannst du bei deinem Ansatz nicht mehr nachträglich einbauen, ohne die Schnittstelle deiner Klasse zu ändern.

Du kannst die interne Repräsentation von amount auch nicht mehr ändern, ohne den Benutzer damit zu konfrontieren.

Ausserdem kann der Verwender jetzt nicht schon beim Setzen des Wertes feststellen, dass er ungültig ist, sondern erst später beim Aufruf von doSomething....

Also ein hoher Preis, den man für das Weglassen der ohnehin üblichen Klammern zahlen muß.

 

[Dibelius]

Ok. Das klingt plausibel, auch was die Java-Konventionen betrifft. Wie gesagt, da denke ich eventuell noch zu sehr in anderen Sprachen, und vermisse den einen oder anderen Komfort, wozu auch optionale Parameter bei Methoden zählen.

Es ist, wie es ist. Ohne entsprechende Sprachelemente ist das so wie von mir gehofft, nicht umsetzbar.

 

[Xyz1]

und vermisse den einen oder anderen Komfort, wozu auch optionale Parameter bei Methoden zählen

Bist du eigentlich eine Frau?

 

[temi]

Wie gesagt, da denke ich eventuell noch zu sehr in anderen Sprachen, und vermisse den einen oder anderen Komfort, wozu auch optionale Parameter bei Methoden zählen.

Vielleicht wäre ja ein Fluent-Interface was für dich?

main.doSomething().with(new int[]{1,2,3}).repeat(5).start()

 

[mrBrown]

Wie gesagt, da denke ich eventuell noch zu sehr in anderen Sprachen, und vermisse den einen oder anderen Komfort, wozu auch optionale Parameter bei Methoden zählen.

Ich persönlich finde ein:

MainClass main = new MainClass();
main.array = new int[]{1,2,3};
main.amount = 3;
main.doSomethingWithCurrentValues();

deutlich umkomfortabler als:

MainClass main = new MainClass(new int[]{1,2,3}, 3);
main.doSomethingWithCurrentValues();

oder auch die Flutent-Interface-Variante, völlig unabhängig von der Sprache.


Optionale Parameter kann man rudimentär mit Überladen oder null lösen, wobei das natürlich nicht so schön wie in anderen Sprachen ist...

 

[Goldi]

[...] und vermisse den einen oder anderen Komfort, wozu auch optionale Parameter bei Methoden zählen.

Denkst Du da an die objektorientierte Supersprache schlechthin mit "Public Sub IchTuWas(ByVal Optional irgendwas As Boolean = False)" - Visual Basic? (Zu meiner Ehrenrettung: Das war Sarkasmus ) ... sorry. Im Ernst: Schlag mal (im Java-Kontext) unter "überladen" nach. Ist das der Komfort von optionalen Parametern, den Du suchst?

 

[Dibelius]

Bist du eigentlich eine Frau?

Bist Du eigentlich ein Forentroll? Tourette?

Vielleicht wäre ja ein Fluent-Interface was für dich?

Das sieht in der Tat interessant aus. Danke!

Ich persönlich finde ein (...) deutlich umkomfortabler (...)

Ja, und Nein. Mein Gedanke war: Keep it simple. Da möchte ich den Benutzer, der die Hauptklasse instanziiert, nicht mit zu viel "Vorarbeit" überfrachten und diese auch nur verlangen, wenn andere Verhaltensweisen vom Objekt gewünscht sind, als die Standardinitialisierungen bestimmter Felder es vorgeben.

Der Code könnte schlicht lauten:

MainClass main = new MainClass();
//main.array = new int[]{1,2,3};
//main.amount = 3;
main.doSomethingWithCurrentValues(); // arbeitet nun mit Standardwerten für 'array' und 'amount'

Optionale Parameter kann man rudimentär mit Überladen oder null lösen, wobei das natürlich nicht so schön wie in anderen Sprachen ist...

Genau. Rudimentär. Mir ist das Konzept von überladenen Methoden bekannt, und offensichtlich ist das der Weg, den Java-Entwickler gehen (müssen).

 

[mrBrown]

Ja, und Nein. Mein Gedanke war: Keep it simple. Da möchte ich den Benutzer, der die Hauptklasse instanziiert, nicht mit zu viel "Vorarbeit" überfrachten und diese auch nur verlangen, wenn andere Verhaltensweisen vom Objekt gewünscht sind, als die Standardinitialisierungen bestimmter Felder es vorgeben.

Das würde man dann mit überladenen Methoden (bei wenigen, unterschiedlichen Parametern) oder Builder-Pattern lösen (wenns die Parameter komplexer werden), letzteres entspricht dann dem Fluent-Interface.

Hat beides auch den Vorteil, dass man immutable Objekte hat

 

[Xyz1]

Bist Du eigentlich ein Forentroll? Tourette?

Wenn ich keine Ahnung habe wie bei Dir offensichtlich der Fall, würde ich so etwas nicht in den Raum stellen.

Tourette ist eine Beleidigung - schonmal nachgedacht?

 

[temi]

Tourette ist eine Beleidigung - schonmal nachgedacht?

Eigentlich ist Tourette ein französischer Neurologe und Psychiater (gewesen)...