Paramterliste bei private Methoden
-
Macht es Sinn bei private Methoden, die folglich nur innerhalb der Klasse bzw. des Objekts verwendet werden, Parameter zu übergeben obwohl dies eigentlich nicht notwendig wäre?
Z.B. könnte man bei einer Klasse Flower, die eine Methode grow([...]) und ein Feld growthRate hat, die Methode grow entweder so aufrufen:
grow();(implizite Verwendung von growthRate)
oder so:
grow(growthRate);(explizite Verwendung)
Was macht mehr Sinn?
Für die 1. Variante spricht IMO das sie kürzer ist, während die 2. Variante Transparanz schafft, da schon beim Aufruf ersichtlich ist mit welchen Daten die Methode arbeitet (und ggf. verändert).
-
Diese Entscheidung würde ich von den Eigenschaften von grothrate abhängig machen. Wenn es eine relativ konstante Eigenschaft der Flower ist würde ich variante 1 nehmen. Wenn die grothrate aber von anderen Dingen wie Licht und Wasserhaushalt abhängig ist und sich somit ständig ändert würde ich die zweite Variante wählen.
-
Das ist eine allgemeine Designfrage, die sich unabhaengig von Java stellt. Von daher waer sie evlt. in RudP besser aufgehoben.
Ich entscheid das im Uebrigen meistens aus dem Bauch heraus.
-
Definitiv das zweite.
-
jimboStar schrieb:
Macht es Sinn bei private Methoden, die folglich nur innerhalb der Klasse bzw. des Objekts verwendet werden, Parameter zu übergeben obwohl dies eigentlich nicht notwendig wäre?
Nein macht es nie!
-
lol was? schrieb:
jimboStar schrieb:
Macht es Sinn bei private Methoden, die folglich nur innerhalb der Klasse bzw. des Objekts verwendet werden, Parameter zu übergeben obwohl dies eigentlich nicht notwendig wäre?
Nein macht es nie!
Doch, macht es!
-
Nein, wer? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
-
lol was? schrieb:
Nein, wer? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
Du würdest also eher für jede noch so kleine Temporäre Berechnung lieber ne Member-Variable anlegen? Wer macht denn sowas? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
-
Mal ein Einwurf:
Private Methoden gehören doch sowieso in das Kapitel Implementationsdetails und werden in lokale Funktionen in der cpp-Datei ausgelagert.
Ist daran etwas dran?
MfG SideWinder
-
Tolpan schrieb:
lol was? schrieb:
Nein, wer? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
Du würdest also eher für jede noch so kleine Temporäre Berechnung lieber ne Member-Variable anlegen? Wer macht denn sowas? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
So ein Quatsch, aber davon war hier auch gar nicht die Rede. Lies evtl. erstmal den Ausgangspost richtig durch.
-
SideWinder schrieb:
Mal ein Einwurf:
Private Methoden gehören doch sowieso in das Kapitel Implementationsdetails und werden in lokale Funktionen in der cpp-Datei ausgelagert.
Ist daran etwas dran?
MfG SideWinder
Ja kein Java.
-
Rhombicosidodecahedron schrieb:
Ja kein Java.
Dort habe ich ja dafür das Konzept Interface. Sehe also mit Java wesentlich weniger Probleme diesbezüglich.
Edit: Offenbar eine Behinderung der Augen meinerseits. Ich war mir 100%ig sicher im C++-Bereich zu sein. Tut mir leid.
MfG SideWinder
-
Tolpan schrieb:
lol was? schrieb:
Nein, wer? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
Du würdest also eher für jede noch so kleine Temporäre Berechnung lieber ne Member-Variable anlegen? Wer macht denn sowas? Außer Looser, die Objektorientierte Programmierung nicht verstanden haben?
Würde ich auch machen. Kommt drauf an, ob es wirklich nur eine sehr temporäre Variable ist.
Wenn man dann auf einmal viele Member-Variablen hat, die viele Berechnungen machen, wird es ersichtlich, dass deine Klasse viele verschiedene Dinge macht und dann sollte man die Berechnungen in eigene Klassen auslagern.