Property oder Methode?

hi spezalist(inn)en!

mal wieder ein philosophisch-konzeptionelles problem!

ich würde gerne mal ein paar meinungen von euch hören, wann man denn nun besser eine namentlich gut erkennbare Methode verwendet und wann man lieber den setter einer Eigenschaft verwenden sollte, um bestimmte Dinge zu erledigen!

Beispiel:
Ich habe eine Klasse View.
Die soll die Fähigkeit haben, sich zu erneuern, z.B. wenn der Benutzer eine Informationskategorie wechselt.
Nehme ich jetzt das Property _filterCriteria _und verwende seinen setter, um die Ansicht neu zu zeichnen (also z.B. ein Requery auf die Datenmenge des Tabellengitters zu machen) oder implementiere ich brav eine Methode Refresh() ?

Von aussen wäre der Unterschied ja nur:
**mit **Setter

myView.filterCriteria = "Type = 'Customer'" 

**ohne **Setter

myView.filterCriteria = "Type = 'Customer'"
myView.Refresh();

Mein Problem ist, dass ich das Gefühl habe, die Kontrolle zu verlieren, wenn implizit durch die Setter zu viel erledigt wird; ich glaube nämlich, man neigt mit der Zeit dazu, die Setter funktional zu überfrachten?

Bin für jede Meinung dankbar!

thanx vorab

ron

Hallo Ron,

in der Tat liegt ein philosophisch-konzeptionelles Problem vor wie Du schriebst.

Ich würde an Deiner Stelle die Properties NUR zur Wertzuweisung benutzen und Funktionalitäten in Methoden "auslagern". (Ergo: Version zwei Deines Posts)

Vorstellbar wäre die Situation, dass Du bevor Du Refresh aufrufst noch eine Methode eines imaginären objekt2 ansprechen musst. Die könntest Du dann als Anweisung nicht mehr dazwischen schieben.

Ausserdem sind Setter eben Setter und keine Methoden 8)
Meine Meinung.

Viele Grüße
🙂 Torsten

hi imich

danke für deinen beitrag.

auf die frage "wann nehme ich eigentlich properties und wann public members?"
hat mir mal ein professioneller c# trainer gesagt, getter und setter sind dann sinnvoll, wenn im rahmen der wertzuweisung "noch andere dinge mit erledigt werden sollen".

deiner meinung nach sollte man nun properties nur zur wertzuweisung verwenden, d.h. du hast grundsätzlich keine öffentlichen felder sondern nur Properties in deinen Klassen?

gruß

ron

Hallo Ron,

ich habe keine Ahnung was das für ein IT-Trainer war, aber fest steht: Properties setzen Werte in private Felder und lesen Felder aus. Grundlage dieser Methodik ist das "Information Hiding"-Prinzip der Kapselung. Nur Felder öffentlich deklarieren wenn unbedingt notwendig! Das jedenfalls bringe ich meinen Schülern immer bei 😁

hth,
🙂 Torsten

Original von citizen.ron

deiner meinung nach sollte man nun properties nur zur wertzuweisung verwenden, d.h. du hast grundsätzlich keine öffentlichen felder sondern nur Properties in deinen Klassen?

gruß

ron

Hallo citizen.ron,

ich habe auch nur Properties in meinem Klassen und keine öffentlichen Felder. Ich benutze Properties, um den Wert, der zugewiesen werden soll, zu überprüfen. Habe ich zum Beispiel eine Integer Variable, die nur Werte zwischen 1-5 annehmen soll, dann überprüfen ich das im Property und schmeiße eine Exception, wenn der Wertebereich abweicht.

Kann es sein, dass der C#-Trainer das mit "bestimmte Dinge zu erledigen" gemeint hat?

Gruß,
Fabian

ok männer, das macht alles total sinn was ihr sagt.

ich fasse also nochmal zusammen:
eine klasse hat felder nur für ihre privaten zwecke.

öffentliche attribute sind immer als properties realisiert.

der setter von properties macht ausser der wertzuweisung maximal dinge wie gültigkeitsprüfung des gesetzten wertes.

d.h. aber, wenn das property so ein komplexes ding ist wie eine eigene klasse, sagen wir mal eine sqlconnection, dann ist es natürlich legitim, dass die gültigkeitsprüfung hier solche dinge umfasst wie "mal gucken, ob die verbindung auch wirklich geöffnet werden kann, initialisiere die felder dbName und serverName, etc.", oder?

🙂 ron

Selbe Spiel hier: Überprüfen der Felder mit Properties und initialisieren mit Methoden 😉

@Fabian: Nette Signatur 😁

@Fabian: Nette Signatur 😄

Hallo the_lmich,

danke danke 🙂. Ist entstanden, als ich für die Berufsschule etwas in Java programmieren musste und dort fast an einem Problem gescheitert wäre, dass ich in C# definitiv nicht gehabt hätte.

Gruß,
Fabian

Ich würde wenns geht, die erste Variante verwenden. Ansonsten kann es doch meiner
Meinung nach leicht passieren, dass sich das Objekt in einem inkonsistenen Zustand
befindet. Implizite Tätigkeiten, die nötig sind, seh ich nicht als "Verlust von Kontrolle".

Hallo Zusammen!

Ich verwende grundsätzlich keine öffentlichen Felder/Attribute innerhalb von Klassen. In der Tat, wenn diese von außerhalb veränderbar/abgreifbar sein sollen, realisiere ich das mit Properties.

Über den Funktionsumfang innerhalb der Getter und Setter lässt sich sicherlich streiten. Ich verwende hier Dinge wie es Fabian schon angesprochen hat, z.B. bei einer Zuweisung, dass ich überprüfe, ob die Zuweisung innerhalb von mir definierten Regeln genügt.

Wie Fabian genannt hatte, z.B. einen Integer auf Range prüfen. Ich habe z.B. auch einen "sehr kleinen" Sql-Command-String Überprüfer geschrieben, und wenn ich ein Sql-Command-String meiner DB-Klasse übergebe, überprüfe ich z.B. ob ein ';' im String vorhanden ist, wenn ja, dann raus mit, bevor ich den internen privaten string setze.

Für solche Dinge verwende ich "code" innerhalb von Getter und Setter. Also alles was nur im direkten Sinne mit der Übergabe zum internen privaten Feld/Attribut zu tun hat.

Eine Überprüfung, ob eine Connection besteht, würde ich dann machen, wenn der Befehl zur Ausführung kommen soll, und bei mir ist das wenn ich mit meiner DB-Klasse z.B. die Methode ExecuteCommand() aufrufe.

Aber es ist reine Geschmacksache, die nicht genau festgelegt werden kann.

In diesem Sinne,
Norman-Timo

Hallo zusammen,

es besteht ja schon mal Einigkeit, dass öffentliche [EDIT]Felder[/EDIT] schlecht sind. Da es auch keinen Grund für sie gibt, sollte man also immer Properties verwenden.

Was die Frage Property oder Methode angeht, ist das m.E. eine Design und keine Programmierfrage. Ihr habt so darauf abgehoben, was der Setter intern alles macht oder machen darf. Das spielt m.E. keine Rolle.

Es geht darum: Ist etwas (designmäßig gesehen) eine Eigenschaft eines Objekts? Eigenschaften sind sowas wie Größe, Gewicht, Länge, Farbe, Beschriftung, ... Wenn ja, dann verwendet man eine Property. Wie viel hinter den Kullissen abgeht, spielt keine Rolle.

Oder gehört etwas zum Verhalten eines Objekts. Verhalten ist z.B. Drucken, Speichern, Anzeigen, Sortieren, ... Wenn ja, dann erstellt man eine Methode.

Die Trennung in Filter setzen und Refresh halte ich für ungünstig. Das wäre nur sinnvoll, wenn man mit dem Objekt nach dem Setzen des Filters und vor der Refresh sinnvoll arbeiten kann, also dadurch ein neuer, wünschenswerter Zustand entsteht. Wenn das nicht der Fall ist, sollte man auf keinen Fall trennen.

herbivore

Hallo Herbivore!

öffentliche Fehler

sind nie gut 😉))

Ciao
Norman-Timo

hey herbivore,

persönlich bringt es für mich dein satz auf den punkt:

Die Trennung von Property und Methode ist nur sinnvoll, wenn für das Objekt nach dem Setzen des Property und vor der Methode ein neuer, wünschenswerter Zustand entsteht.

Und das ist eben manchmal einfach nicht so, also ab in den setter mit dem code!

da ich nicht alles hier gelesen habe 8), werde ich vielleicht jemanden hier wiederholen.

ich bin der Meinung, dass die Vorgehensweise Property setzen, Refresh aufrufen eigentlich nur Nachteile hat (es gibt natürlich auch Ausnahmen).
Der Code wird dadurch nur länger. Es werden dadurch viele Automatismen außer Kraft gesetzt. Da denke ich spontan an das Binding-Konzept oder automatische Codegenerieren.
Kontrolle verliert man dadurch auch nicht. Es gibt auch Konstrukte wie BeginUpdate, EndUpdate, um sofortiges Erneuern zu unterbinden.

P.S. ich hatte da noch irgendwas, aber bis ich das hier fertig geschrieben habe, habe ich es vergessen. 😁

Oder machs doch nach dem Schema

...
...
class myView
{
  private string myfilterCriteria;

  public string filterCriteria
  {
    get
    {
      return myfilterCriteria;
    }
    set
    {
      ...
      ...
      myfilterCriteria = value;
      this.Refresh();
    }
  }

  public void Refresh()
  {
    ...
    ...
    ...
  }

}

natürlich nur falls es so geht 😉
habe das noch nicht ausprobiert

Hallo Altstetter,

wenn Refresh protected wäre, könnte man drüber reden 🙂

herbivore

Öffentliche Felder machen IMHO durchaus Sinn, nämlich dann, wenn sie z.B. als readonly deklariert werden und der getter auch nichts anderes macht als ein simples return des Wertes.

Beispiel Singleton: An Stelle von

public static class Singleton<T> where T : new()
{
    private static T instance = new T();
    
    static Singleton()
    {
    }
    
    public static T Instance
    {
        get
        {
            return instance;
        }
    }
}

würde ich eher

public static class Singleton<T> where T : new()
{
    public static readonly T Instance = new T();
    
    static Singleton()
    {
    }
}

verwenden.

Viele Grüße,

Golo

Original von citizen.ron
ich würde gerne mal ein paar meinungen von euch hören, wann man denn nun besser eine namentlich gut erkennbare Methode verwendet und wann man lieber den setter einer Eigenschaft verwenden sollte, um bestimmte Dinge zu erledigen!

Da im Prinzip beide Varianten identisch sind, lohnt es mal einen Blick auf die Unterschiede zu werfen:

1. Setter können Fehler nur über Exceptions anzeigen, Set-Funktionen können dagegen auch Fehlerwerte liefern. Genau daraus leitet sich die Verwendung einer Set-Funktion ab: Führt das Setzen eines Wertes häufig zu einem Fehler, bzw. ist hier der Steuerfluss involviert, sollte man lieber zu einer Set-Funktion greifen, sonst immer Property/Setter.

2. Properties haben bei Controls und bei der Serialisierung speziellen Charakter. Hier sind Set-Funktionen keine Alternative.

Daher: Set-Funktionen machen nur in extrem seltenen Ausnahmen Sinn, bzw. bringen nur dann einen Vorteil.

hi svenson

good point!

habe aus diesem thread tatsächlich nützliche inspirationen bezogen. liebe diese community einfach 😉

gruß

ron

Hallo Der Eisbär,

damit bekommst du aber genau die in Globale Konstanten beschrienenen Versionierungsprobleme. Wenn du aber eine Property verwendest, kannst du auch nachträglich noch was anderes machen, als das return.

Mal abgesehen davon, dass Property oder Feld bezüglich der Serialisierung einen Unterschied macht (wenn sie non-static sind).

Also Grundsatz sollte man also schon immer Properties verwenden.

herbivore

Das Versionierungsproblem sollte eigentlich nur bei Konstanten auftreten. Read-Only-Member werden zur Laufzeit gelesen. Insofern sind read-only-static-Variablen durchaus eine Alternative zur Verwendung von Konstanten.

Aber hier gings ja um Properties vs. Setter-Funktionen...

Hallo svenson,

habe ich auch gedacht, aber ich habe es ausprobiert, wenn du eine readonly mit einem Literal initialisierst, dann verhält sich das wie eine Konstante (ok, ist hier nicht der Fall).

Aber es ging mir ja darum, wenn man aus "public static readonly T Instance" später eine Property macht (machen muss), kriegt man auch Probleme, wenn man nur die definierende Assembly übersetzt, die man nicht hätte, wenn es gleiche eine Property ist, die man dann nur ändert.

herbivore

Original von herbivore
habe ich auch gedacht, aber ich habe es ausprobiert, wenn du eine readonly mit einem Literal initialisierst, dann verhält sich das wie eine Konstante [...]

Spannend, gleich mal testen.

Die C#-Spec sagt dazu:

"Constants and read-only shared variables have different semantics. When an expression references a constant, the value of the constant is obtained at compile time, but when an expression references a read-only shared variable, the value of the shared variable is not obtained until run time."

Wenn es sich so verhält, wie du es sagst, wäre das ein Bug.