C# Parameter (CleanCode Tipp)

[tollertyp]

Estimate ist auch ein Substantiv, aber ja, wie rum und wie man die Methode benennt ist ja dann ne Stilfrage.

Wieder was gelernt, für mich war estimate immer nur ein Verb. Aber Methoden/Funktionen sollten auch ein Verb enthalten.

 

[Hancock]

ich ging jetzt einfach mal davon aus, dass die benannten Funktionen public Methoden der Klasse schon bereits sind?

Dann würde man aber nicht das Objekt als ersten Parameter in der Methodensignatur haben. Das wird implizit als this übergeben.

Generell +1 nur die Parameter, nicht das ganze Objekt, aus den genannten Gründen.

Nur die Parameter macht nur bei einem mathematischen Modell wirklich Sinn. Z.B.

public double estimateConsumptionLaminarCW(double frontArea, double speed, double cw){
return frontArea*cw*speed*speed;
}

Das Interface bricht aber in sich zusammen wenn man unterschiedliche Modelle hat, oder mglw. sogar Messdaten:

public double estimateConsumption(double frontArea, double speed, double cw){
return interpolate(AudiA3_meas_2019_03_12_testdrive_schumacher,speed);//BAD
}

Wäre definitiv richtig schlechter Code, bad practice und die Definition von schlechter Kapselung.

 

[AW4]

Sowas weiß man immer erst "hinterher".
Sprich: Dann, wenn du deinen Code für Erweiterungen noch mal anfassen musst.

Ich habe deswegen früher immer versucht abzuschätzen, was die Zukunft potentiell noch so bringen könnte und habe dann die Architektur darauf ausgerichtet.
Problem daran war nur, dass in den meisten Fällen eine Erweiterung ausbliebt und wenn nicht, lagen meine vergangenen Gedanken, bzgl. der Auslegung der Architektur, zum Großteil sehr daneben und die damalige Mehrarbeit war faktisch nicht zu gebrauchen.

Meine Empfehlung deshalb:
Mach es dir im Anbetracht der Anforderungen so einfach wie möglich.
Spart Zeit und Komplexität.
Und vor allem die geringere Komplexität führt zur Reduktion von potentiellen Fehlern und bringt auch gleich den Vorteil, dass der Code und seine Intentionen vom aktuellen und zukünftigen "Du", sowie von dritten einfacher verstanden werden kann.

Etwas spezifischer zu deiner ursprünglichen Frage:
Primär musst DU deinen Code verstehen.
DU bist der, der ihn schreibt und der ihn möglichst fehlerfrei halten muss.
DU bist hier also bei solchen Entscheidungen der Dreh- und Angelpunkt.
Wenn du bestimmte Anforderungen an deinen Code hast, wie z.B. sehr gute Lesbarkeit, hohe Wartbarkeit, hohen Wiederverwendungsgrad, möglichst breite und umfangreiche Auslegung, einhalten bestimter Standards oder Prizipien, etc., dann ist das immer ein Prozess!
Da gibt es keinen Schalter.
Du kannst, bzw. solltest vorher natürlich recherchieren, nach Meinungen Fragen und musst dir zwangweise Gedanken machen.
Am Ende solltest du aber genau das machen, womit du am besten klar kommst.
Nach getaner Arbeit musst du dir dein Werk noch einmal anschauen und bewerten ,was gut und was scheiße war.
Beim nächsten Mal machst du dann "einfach" mehr vom Guten und weniger vom Beschissenen.

 

[tollertyp]

@AW4: Clean Code bedeutet ja auch nicht, auf Anhieb den perfekten Code zu schreiben.

Und Schnittstellen auf Wiederverwendbarkeit hin auszulegen ist meistens erst dann sinnvoll, wenn man wirklich einen zweiten oder noch besser auch einen dritten Konsumenten der Schnittstelle hat.

 

[Ghost_Rider_R]

Und Schnittstellen auf Wiederverwendbarkeit hin auszulegen ist meistens erst dann sinnvoll, wenn man wirklich einen zweiten oder noch besser auch einen dritten Konsumenten der Schnittstelle hat.

Das ist bei mir auf absehbare Zeit auch nicht der Fall, daher würde es mein aktuelles Probjekt nur unnötig aufblasen.

Ich denke AW4 hat es hier ganz treffend beschrieben. Alles ist möglich und erlaubt und kommt in der Praxis so wohl auch vor.

Danke für eure Meinung.