Es sollte niemals ein Parameter vom Typ bool oder boolean verwendet werden. Warum? Erinnert ihr euch noch an den Punkt „Eine Funktion hat genau eine Aufgabe“? Was werden wir mit einem boolchen Parameter wohl anstellen? Wahrscheinlich folgendes:<\/p>\n
public void Foo(bool bar)\r\n{\r\n\tif(bar)\r\n\t{ \r\n\t\t\/\/ mach was\r\n\t}\r\n\telse\r\n\t{\r\n\t\t\/\/ mach was anderes\r\n\t}\r\n}<\/pre>\nMethoden mit boolchen Parametern erf\u00fcllen also in aller Regel mehr als eine Aufgabe.<\/p>\n
Das gleiche Prinzip gilt auch f\u00fcr die Bedeutung eines Parameters mit dem Wert null. Wenn wir folgenden Methodencode haben, erf\u00fcllt die Funktion ebenfalls mehr als eine Aufgabe:<\/p>\n
public void Foo(object bar)\r\n{\r\n\tif(bar == null)\r\n\t{ \r\n\t\t\/\/ mach was\r\n\t}\r\n\telse\r\n\t{\r\n\t\t\/\/ mach was anderes\r\n\t}\r\n}<\/pre>\nEine Pr\u00fcfung der eingehenden Parameter auf null ist demgegen\u00fcber allerdings g\u00fcltig:<\/p>\n
public void Foo(object bar)\r\n{\r\n\tif(bar == null)\r\n\t{ \r\n\t\tthrow new ArgumentNullException(\"bar\", \"Parameter 'bar' darf nicht null sein.\")\r\n\t}\r\n\t\r\n\t\/\/ mach was\r\n}<\/pre>\nStreng betrachtet erf\u00fcllt diese Methode zwar zwei Aufgaben (1. Pr\u00fcfen der Parameter, 2. „was machen“), halten wir uns aber an diese Struktur – erst pr\u00fcfen, dann den eigentlichen Code ausf\u00fchren – ist die Methode weiterhin gut lesbar.<\/p>\n
In .Net sollten wir zudem darauf achten, keine out-Parameter zu verwenden. Ein Beispiel:<\/p>\n
bool TryGetCustomer(int customerId, out Customer customer)\r\n{\r\n\u00a0\u00a0 \u00a0customer = GetCustomerById(customerId);\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0if(customer == null) \r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return false;\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0else\r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0return true;\r\n\u00a0\u00a0 \u00a0}\r\n}<\/pre>\nDer Aufrufer der Methode muss nun zwei Werte verarbeiten: 1. den R\u00fcckgabewert (bool) und den eigentlichen, von der Methode ermittelten Wert (customer). Besser w\u00e4re es hier, direkt den Customer zur\u00fcckzugeben und den Aufrufer auf null pr\u00fcfen zu lassen (wie es etwa die Methode GetCustomerById(int customerId) macht, die hier aufgerufen wird). Alternativ k\u00f6nnen wir den Umstand des nicht gefundenen Werts als Ausnahme betrachten und eine entsprechende Exception werfen:<\/p>\n
Customer TryGetCustomer(int customerId)\r\n{\r\n\u00a0\u00a0 \u00a0customer = GetCustomerById(customerId);\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0if(customer == null) \r\n\u00a0\u00a0 \u00a0{\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0throw new CustomerNotFoundException(customerId);\r\n\u00a0\u00a0 \u00a0}\r\n\u00a0\u00a0 \u00a0\r\n\u00a0\u00a0 \u00a0return customer;\r\n}<\/pre>\n <\/p>\n
\u00a0\u00dcberraschung!<\/strong><\/p>\nWas f\u00e4llt euch beim folgenden Code auf?<\/p>\n
void SetActiveCustomer(Customer customer)\r\n{\r\n\u00a0\u00a0\u00a0 this.activeCustomer = customer;\r\n\u00a0\u00a0\u00a0 this.customerList.Add(customer);\r\n}<\/pre>\nDenkt mal kurz dar\u00fcber nach, was die Methode macht……….<\/p>\n
Sie setzt einen „aktiven Kunden“ in einer Klasse. Das sagt zumindest der Name der Methode aus. Tats\u00e4chlich wird aber nicht nur der aktive Kunde auf den \u00fcbergebenen Wert festgelegt, sondern dieser \u00fcbergebene Wert auch in eine Kundenliste eingef\u00fcgt.<\/p>\n
Wollten wir das, wenn wir die Methode SetActiveCustomer<\/em> aufrufen? Wahrscheinlich nicht. Dieses Verhalten ist f\u00fcr uns eine \u00dcberraschung…und \u00dcberraschungen k\u00f6nnen wir nicht leiden (wenigstens nicht im Code). Wenn wir sp\u00e4ter auf diese customerList zugreifen, sind dort pl\u00f6tzlich Werte enthalten, die wir dort gar nicht erwarten, weil wir sie nicht hinzugef\u00fcgt haben. Zumindest nicht wissentlich.<\/p>\nMethoden sollten immer nur genau das tun, was ihr Name sagt. Sie sollten keine Nebeneffekte haben. Wenn der Aufrufer diesen Wert auch in diese Liste einf\u00fcgen will, dann soll er das explizit tun.<\/p>\n
Zusammenfassung<\/h3>\n
Der Artikel ist ganz sch\u00f6n lang geworden. Bei Funktionen gibt es f\u00fcr uns so einiges zu beachten. Zun\u00e4chst sollen sie klein sein. Sehr klein. Noch kleiner. Funktionen k\u00f6nnen gar nicht klein genug sein. Dann sollten sie einen sprechenden Namen haben und genau die Aufgabe ausf\u00fchren, die in diesem Namen angegeben ist. Und nur genau diese eine Aufgabe. Keine weiteren Aufgaben, keine \u00fcberraschenden Aktivit\u00e4ten.<\/p>\n
Wenn wir dies beherzigen, werden unsere Methoden schon \u00fcbersichtlich, unser Code sprechend und viel leichter zu lesen und zu debuggen.<\/p>\n
Viel Spa\u00df beim Anwenden,<\/p>\n
Eure Spa\u00df-Coder<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo Spa\u00df-Coder, im Artikel Basics? Kenn\u2019 ich doch schon! haben wir begr\u00fcndet, warum grundlegende Programmierpraktiken sinnvoll und hilfreich sind. Einige dieser Basics betrifft insbesondere Funktionen in unserer Programmierung. Dar\u00fcber m\u00f6chten wir im folgenden ein wenig sprechen. Regeln f\u00fcr Funktionen Frei nach Uncle Bob (Robert C. Martin) – es gibt zwei Regeln zu Funktionen: Funktionen […]<\/p>\n","protected":false},"author":1,"featured_media":302,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[22,90],"tags":[23,18,37,35,29,36],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/297"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=297"}],"version-history":[{"count":3,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/297\/revisions"}],"predecessor-version":[{"id":300,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/297\/revisions\/300"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/302"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=297"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}