Ihr wollt für ein neues Feature etwas hinzufügen und merkt das ihr an 35 Codestellen, wo If-Abfragen verwendet werden, den Source Code ändern müsst. Na super!
Das Problem kennt ihr sicherlich. Ihr führt die Änderungen durch und dann müsst ihr im Anschluss natürlich alle Stellen testen, ob diese noch funktioniert oder nicht. Das bringt nicht nur kein Spaß, dass ist auch Verschwendung von Zeit und Geld. Das ist nicht praktikabel. Das geht besser. Ich rufe euch zur Teilnahme an der Anti-If-Campaing auf:
http://www.antiifcampaign.com/join-the-campaign.html
Worum geht es hier? If-Bedingungen haben große Auswirkungen auf den Code. If-Bedingungen können gefährlich sein. Stattdessen sollte man lieber Objekte bauen, damit der Code flexibel, änderbar und einfach zu testen bleibt. Was habt ihr davon? Weniger Kopfschmerzen und mehr Freizeit. Es geht also um das effiziente Codieren, Software Design Prinzipien und Best Practies.
Im nächsten Artikel dieser Reihe stelle ich Techniken vor, wie ihr auf If-Bedingungen verzichten könnt und bessere Software entwickelt, die sich schnell ändern und erweitern lässt.