hilfe bei Refactoring Übung

[Cristina]

Hallo, 

Kann mir jemand helfen die Lösung aus diese Übung von das Büch Fachinformatiker Anwendungsentwickler zu verstehen:

Was ich nicht nicht verstehe ist warum habe sie die Methoden wie das gebaut. 

Vielen Dank 

Cristina 

 

 

 

 

 

Bearbeitet 3. April 2022 von Cristina

[Whiz-zarD]

Witzigerweise sind x_Koord und y_Koord nicht mal die richtigen Bezeichner, da x und y Ordinaten sind und erst beide zusammen eine Koordinate bilden. 😄

Abstand_Ursprung() soll ja den Abstand vom Mittelpunkt des Koordinatensystems (wenn x und y gleich 0 sind) bis zum Punkt errechnen. Also kann man auch einen Punkt mit x = 0 und y = 0 definieren und dann Abstand_Punkt() aufrufen. Man sieht ja im Urspungscode, dass der Satz des Pythagoras in zwei Methoden verwendet wird. Im refaktorisierten Code wird der Satz des Pythagoras nur noch in einer Methode verwendet, was die Fehleranfälligkeit minimiert. Hier wurde also das sog. DRY-Prinzip angewendet.

[be98]

Kann man so machen. Ich find dir Methode Abstand ursprung etwas seltsam. Die kann man sich eigentlich auch sparen. 

[Rienne]

@be98 wieso kann man sich die sparen? Wenn es die Anforderung ist, dass du den Abstand eines Punktes zum Ursprung willst, macht diese durchaus Sinn. Handys haben ja z.B. auch eine extra Notruf-Funktion, auch wenn die Funktionalität dahinter ggf. die gleiche ist, wie bei "Nummer wählen", nachdem du eine eingegeben hast, nur dass eben eine fest vorgegebene Nummer gewählt wird. Analog verhält es sich mit den Methoden "Abstand_Ursprung" und "Abstand_Punkt". Der Aufrufer der Methode "Abstand_Ursprung" muss sich keine Gedanken darüber machen, welchen Wert der Ursprung hat, so wie der Anrufende sich keine Gedanken darüber machen muss, welche Nummer bei einem Notruf zu wählen ist.

[be98]

Ja gut, verstanden. Ist schon manchmal praktischer

[Gast D-eath]

Ich würde das Strategy Pattern verwenden, um die Berechnungsart für den Abstand von außen zu injizieren. Das macht alles auf jeden Fall lesbarer.

Scherz. Zur Musterlösung: Man kann sich den Default-Konstruktor auch ggf. sparen und die Variablen direkt mit 0 vorbelegen. Außerdem JavaDoc nutzen, damit der Nutzer einer IDE nicht in den Code springen muss, sondern direkt sieht, was die Methode tut (bspw. im Autocomplete) - die Kommentare zur Beschreibung der Funktion der Methode innerhalb der Methode erfordern hier Springen im Code - nicht sinnvoll. In dem Einstiegspunkt könnte die Musterlösung auch noch korrekte Einrückung nutzen. Die Variablen in Abstand_Punkt heißen nicht delta_x / delta_y (wie im Kommentar), sondern d_x und d_y. Könnte man auch korrigieren.

Ansonsten zielt das neben Renaming hier wie schon beschrieben auf das DRY-Prinzip (Don't repeat yourself) ab.

[Tiwil]

Punk

vor 31 Minuten schrieb D-eath:

Man kann sich den Default-Konstruktor auch ggf. sparen und die Variablen direkt mit 0 vorbelegen.

Sicher? Wenn man einen parametrisierten Konstruktor nutzt, muss doch ein no-arg-Konstruktor gleichzeitig definiert werden? Oder täusche ich mich da?

[Whiz-zarD]

vor 57 Minuten schrieb Tiwil:

Punk

Sicher? Wenn man einen parametrisierten Konstruktor nutzt, muss doch ein no-arg-Konstruktor gleichzeitig definiert werden? Oder täusche ich mich da?

Ja, das muss man. Allerdings sollte dann der Standard-Konstruktor den parametrisierbaren Konstruktor aufrufen. Ich hätte auch noch die privaten Felder mit final versehen, um Seiteneffektfehler zu verhindern.

public class Punkt {
  private final int x;
  private final int y;
  
  public Punkt() {
    this(0, 0);
  }
  
  public Punkt(int x, int y) {
    this.x = x;
    this.y = y;
  }
  
  //...
}

 

Bearbeitet 7. April 2022 von Whiz-zarD