Laden...

Liste von Parametern übergeben oder ein gekapseltes Parameter-Objekt?

Erstellt von barzefutz vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.267 Views
B
barzefutz Themenstarter:in
95 Beiträge seit 2007
vor 11 Jahren
Liste von Parametern übergeben oder ein gekapseltes Parameter-Objekt?

Und ich nochmal 🙂

Nehmen wir an, ich habe eine Methode, die Dateien suchen soll. Diese soll eine Reihe Suchparameter entgegennehmen, beispielsweise ob Groß- und Kleinschreibung berücksichtigt werden soll, ob Unterverzeichnisse durchsucht werden sollen, ob versteckte Dateien berücksichtigt werden sollen etc. Dann habe ich zwei Möglichkeiten, diese Parameter zu übergeben. Einmal so:

Suche(bool großklein, bool unterverzeichnisse, bool hiddenfiles)

Oder ich erstelle ein spezielles Objekt, was die Suchparameter kapselt, beispiel:

class SuchOptionen
bool großklein
bool unter
bool hidden

Und übergebe dann beim Suchen eine Instanz davon:

Suche(SuchOptionen)

Was würdet ihr bevorzugen? Ein gewichtiges Argument für die zweite Methode ist natürlich, dass wenn sich die Suchparameter ändern, ich nicht überall die Parameter in den Methodendefinitionen anpassen muss. Ein Argument dagegen könnte sein, dass es vielleicht Overkill ist, zumal ich die Klasse nur ein einziges Mal brauche.

B
barzefutz Themenstarter:in
95 Beiträge seit 2007
vor 11 Jahren

Mir fällt dazu gleich noch eine ähnliche Frage ein. Kreativitätsflash gerade 🙂
Nehmen wir an, ich habe eine Methode, die nach Personen anhand deren ID sucht. Da hätte ich dann auch wieder zwei Möglichkeiten bezüglich der Parameter. Entweder, ich übergebe als Suchparameter nur die ID, oder ich übergebe ein komplettes Person-Objekt, welches die ID ebenfalls beinhaltet:

SuchePerson(int id)

oder

SuchePerson(Person p)

Jetzt auch wieder die Frage, was ist besser (ordentlicher, ressourcenschonender, was auch immer)?

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo barzefutz,

wenn die Parameter zusammengefasst ein eigenständiges, klar benennbares Ding ergeben, wie im Beispiel von den Suchparametern, kann man dass schon machen. Wenn man das "Ding" dann auch an mehreren Stellen braucht oder über mehrere Ebenen durchreichen muss, bietet es sich sogar an. Ist auf jedenfalls besser, als eine dass man immer raten oder nachschauen muss, was nun welcher bool-Wert bedeutet. Dein Aufruf würde ja auf Suche(true,false,true) hinauslaufen. Da sollte man zumindest Enums definieren, damit sich der Aufruf besser liest, Suche(SerachOption.IgnoreCase|SerachOption.IncludeHiddenFiles).

Was die Personensuche angeht, halte ich die Übergabe eines Personen-Objekts für relativ sinnfrei.(*) (Möglicherweise ist es weniger die Kreativität, als die durch Müdigkeit verminderte Selbstüberprüfung der Gedanken. 😃

herbivore

(*) Ein Objekt mit einer bestimmten ID sollte es immer nur einmal (im Hauptspeicher) geben. Andersherum gesagt, sollte es keine zwei (gleiche oder verschiedene) Objekte mit der gleichen ID geben. Wenn man das eine Objekt mit einer bestimmten ID schon hat, braucht man es nicht zu suchen. Wenn man das eine Objekt noch nicht hat, müsste man es erst suchen, was aber nicht geht, wenn man es zum Suchen bereits als Parameter übergeben muss. Da beißt sich die Katze in den Schwanz.

B
barzefutz Themenstarter:in
95 Beiträge seit 2007
vor 11 Jahren

Vielen Dank für deine Antwort. Stimmt, Enums hatte ich völlig vergessen. Ich stehe allerdings gerade etwas auf dem Schlauch. Wo ist genau der Unterschied bzw. Vorteil, ob ich jetzt

Enum SearchOptions
{
  IncludeHidden, IgnoreCase
}

oder

class SearchOptions {
  bool IncludeHidden
  bool IgnoreCase
}

nehme? Funktionieren tut doch beides, oder? Nur dass Enum halt Zahlen und die Klasse booleans benutzt.

Es ist echt krass, habe drei Jahre nicht mehr programmiert und schon wieder alles vergessen X(

16.806 Beiträge seit 2008
vor 11 Jahren

Das sind ja jetzt nun die Grundlagen, was die Vorteile eines Enums sind.
Dazu gehört eben die Flag-Möglichkeit, wie sie herbivore in seiner ersten Antwort gezeigt hat.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo barzefutz,

erstmal möchte ich bekräftigen, dass es sehr im Richtung Grundlagen driftet (und im Grund schon von Anfang nah an den Grundlagen war). Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 1.1.1.

Des runden Abschlusses wegen trotzdem noch eine kurze Ergänzung: Natürlich könnte man im Ergebnis auch bei deiner SerachOptions-Klasse die einzelnen Optionen kombinieren, wie man sie auch mit Flags-Enums kombinieren kann. Aber bei (Flags-)Enums ist man (vereinfacht gesagt) auf boolsche Entscheidungen festgelegt, bei einer SerachOptions-Klasse kann man Propertys beliebiger Typen mischen, (später) z.B. einen Integer für die Suchtiefe hinzufügen.

herbivore

C
224 Beiträge seit 2009
vor 11 Jahren

Ergänzung:

Ich denke, das ist nicht nur das Problem Enums zu kennen, sondern insbesondere auch die Findung nach dem richtigen Entwurfsmuster. Ich z.B. neige dazu stets viele Parameter einfacher Art zu übergeben. Merke ich später, dass ich diese Parameter durch viele Funktionen durchschleifen muss, dann merke ich, dass mein Design kaputt ist. Dann mache ich daraus eine Klasse oder überlege mir, ob diese vielen Funktionen so noch Sinn machen.

Gruß, CoLo