| 

.NET C# Java Javascript Exception

3
Ich habe hier eine Klasse (in C#), die auch Dateien liest und in Dateien schreibt. Die Dateinamen sind in der Klasse hard gecoded. Jetzt will ich in dieser Klasse eine Funktion schreiben, die zurück geben soll, ob diese Datei schon existiert oder nicht. Nun habe ich mir aber auch überlegt, dass man dies genauso als Eigenschaft schreiben könnte, die zurück gibt, ob die Datei existiert oder nicht.

Nun die Frage an euch: Wie seht ihr das? Wann ist es besser, eine Funktion zu nutzen und wann ist es besser, eine Eigenschaft zu nutzen?
26.03.2012
starki 603 1 1 8
5 Antworten
3
Hallo.

Wenn man sich anschaut wie das im .NET Framework gemacht wird, dann müsstest du es eigentlich als Funktion implementieren.
Die File-Klasse im Framework hat auch eine Exists-Funktion, die prüft, ob eine Datei vorhanden ist oder nicht.

Ich würde des wohl auch als Funktion implementieren.

Gruß
Jörg
26.03.2012
multi1209 848 1 8
2
Hi starki,

ich nehme Properties nur als "bessere" Felder, d.h. um ChangeNotification o.Ä. zu implementieren. Sobald der Code in einer Property nicht mehr in seinem Zeitverhalten einschätzbar ist (z.B. Laden des Werts aus einer Datenbank o.Ä.), verwende ich Methoden, denn für mich suggerieren Properties (ebenso Felder) einen schnellen Zugriff. Was "schnell" bedeutet, muss man für sich selbst bestimmen.

Ein weiteres Indiz eine Methode zu verwenden, ist die Anzahl Codezeilen in einer Property (z.B. < 5) bzw. ihre zyklomatische Komplexität (z.B. < 3). Wenn Du Tools hast, die das direkt am Member visualisieren (z.B. CodeRush), kann man das in der IDE anhand eines solchen Zahlenwerts beurteilen (wenn man das möchte). Man erkennt das IMHO auch mit bloßem Auge.

Ansonsten könnte man einfach der genutzten Funktionalität folgen und eine Property implementieren, wenn auch eine Property genutzt wird.

Für Dein Beispiel hast Du jetzt allerdings die Wahl: Machst Du es wie die Methode File.Exists(...) oder die Property FileInfo.Exists. Ab hier wird's dann spätestens akademisch. Meine pragmatischen Ansätze habe ich oben geschildert.

Florian
26.03.2012
ffordermaier 8,4k 3 9
2
Eine allgemeine Regel ist mir nicht bekannt. Meiner Meinung nach bilden Eigenschaften zunächst in irgendweiner Weise den internen Status einer Instanz ab, greifen also nicht auf weitere externe Resourcen zu. Bei Eigenschaften erwarte ich auch umgehende Rückmeldung, also keine längeren Laufzeiten. Funktionen würde ich für gegenteilige Anwendungen bevorzugen, oder auch wenn Vererbung im Spiel ist. Die Verwendung von Parametern macht die Funktion in der Regel zum Sieger. Dem Beispiel nach würde ich eine Funktion verwenden. Vergleiche aber bitte mal Exists der Klassen File und FileInfo.
26.03.2012
me 1,1k 2 9
2
Ich verwende Properties immer dann, wenn sich der Wert oder Zustand nicht durch äußere Einflüsse verändert kann/darf. Also der Dateiname ist ein Property, der kann sich nicht einfach so ändern. Ob die Datei existiert, ist hingegen für mich eher eine Funktion.

Einfach gesagt verfahre ich so: Alles, was sich theoretisch in einer Variablen cachen lässt, ist ein Property, alles was aufgrund äußerer Umstände ständig abgefragt werden muss, ist eine Funktion.

Eine Person hat einen Namen --> Property, ändert sich nicht von selbst
Eine Person hat ein Geburtsdatum --> Property, ändert sich nicht von selbst
Hat die Person heute Geburtstag? --> Funktion, kann sich schließlich ständig wechseln, wenn Mitternacht verstreicht
10.04.2012
commänder 420 1 7
1
Gründe, die für eine Property sprechen:

  • es repräsentiert eher einen Teil des Zustands des Objektes als seine Funktionalität (FileInfo z.B. stellt den Zustand einer Datei zu einem bestimmten Zeitpunkt dar, deshalb ist Exists hier eine Property)
  • könnte auch ein Feld sein bzw. wird tatsächlich intern durch ein Feld abgebildet
  • eher einfache Implementierung
  • kurze Laufzeit
  • wirft keine Exception
  • liefert bei wiederholten Aufrufen auf dem selben Objekt, ohne dass dieses verändert wird, den selben Wert (DateTime.Now ist insofern kein gutes Vorbild, das wäre besser eine Methode)
  • es ist sinnvoll oder zumindest nicht störend, den Wert im Debugger als Teil der Darstellung des Objektes angezeigt zu bekommen
  • der Aufruf hat keine Seiteneffekte (wichtig nicht zuletzt wegen des Debuggers)


Gründe, eine Methode zu verwenden:

  • es geht eher um Funktionalität/Logik als Zustand
  • es werden Parameter benötigt (schon aus dem Grund kann File.Exists(string path) nur eine Methode sein, im Gegensatz eben zur FileInfo, die zu einem bestimmten Pfad gehört, der im Konstruktor angegeben wurde)
  • ein oder mehrere der obigen Indizien für die Verwendung einer Property werden verletzt


Was nun bei Dir geeigneter wäre, kann ich aus Deiner Beschreibung nicht eindeutig herauslesen.

Ich habe hier eine Klasse (in C#), die auch Dateien liest und in Dateien schreibt.

Was tut die Klasse denn noch, und tut sie vielleicht zuviel?
10.04.2012
Matthias Hlawatsch 13,2k 4 9

Stelle deine .net-Frage jetzt!