Neulich kam ich zu einem Stück Code, das die Erzeugung einer SEPA-Datei steuert. Der Autor wollte es sich einfach machen – gute Idee – und hat die Erzeugung von “SEPA Credit Transfer” und “SEPA Direct Debit CORE/COR1″ zusammengelegt – schlechte Idee.
Es ist eine schlechte Idee, weil unterschiedliche Aufgaben in unterschiedlichen Klassen erledigt werden sollten. Die oben referenzierte Klasse sieht auf den ersten Blick vernünftig und aufgeräumt aus. Nur getGeneratedXml fällt aus dem Rahmen. Der Autor benutzt die Variable $mode um die beiden Fälle auseinander zu halten, siehe Kommentar in Zeile 103.
Es ist eine schlechte Idee, weil man riskiert, das eine Verfahren zu beschädigen, wenn man an dem anderen Verfahren arbeitet – sei es aus fachlichen Gründen, sei es aus Versehen. Und es ist eine schlechte Idee, weil ein langer Code-Abschnitt unübersichtlich ist und deswegen komplizierter zu warten als ein kurzer.
Wie kommt jemand auf eine solche Idee? Nun, das zu erzeugende XML ist für beide Fälle in vielerlei Hinsicht gleich. Es gibt nur kleine Unterschiede hier und da … ad hoc kommt der Gedanke: also treffe ich eine entsprechende Fallunterscheidung.
Ich denke, dass folgender Aufbau schlauer ist: Erstens gibt es eine abstrakte Klasse SepaXmlCreator, die alle Gemeinsamkeiten enthält und Platzhalter für die Unterschiede hat. Zweitens gibt es eine Klasse SepaXmlCreatorCT, die von SepaXmlCreator erbt und die Platzhalter in der Weise ausfüllt, wie es für den Credit-Transfer spezifisch ist. Drittens gibt es eine Klasse SepaXmlCreatorDDC, die von SepaXmlCreator erbt und die Platzhalter in der Weise ausfüllt, wie es für die Lastschrift spezifisch ist. Man nennt das Muster “Schablone”.
Das Allgemeine und das Besondere, Essenz und Akzidenz. Unterscheiden können. Typisch philosophisch. Frohes Neues Jahr!