(30.04.04 09:38)

Ich habe mich bereits früher über den übertriebenen Einsatz von XML in unserer Branche geäussert (Der XML-Hammer ). Gerade für Konfigurationsdaten erfreut sich XML grosser Beliebtheit. Leider wird die Verwaltung solcher Konfigurationen in vielen Projekten bald zum Albtraum.

Abstraktion in den Code – Details in die Daten. Dieser Grundsatz verleitet geradezu zur missbräuchlichen Verwendung von XML. Das Ziel ist dabei so klar wie nützlich: erhöhte Flexibilität und verbesserte Wartbarkeit durch konsequente Trennung der Algorithmik von ihrer tatsächlichen Verwendung. Daten verlieren ihren passiven Charakter und werden zum steuernden Element, welches die mögliche Varianz in unseren Anwendungen bestimmt. Ein Algorithmus (die Abstraktion) wirkt nicht nur auf den Daten sondern die Daten bestimmten aktiv den zu wählenden Algorithmus. Dieser Gedanke steht letztlich auch hinter dem Konzept des Polymorphismus in der Objektorientierung und ermöglicht uns, die Flexibilität in unseren Anwendungen zu erhöhen. Doch die durch die Metaprogrammierung herbeigeführte Trennung eines Algorithmus von seinen Daten ist nicht unproblematisch. Wie Martin Fowler nämlich treffend bemerkt, sind diese Daten Teil des Programmes. Vergessen wir diese Tatsache auch nur für einen kurzen Augenblick, dann stecken wir ziemlich schnell bis zum Hals im Schlamassel.

Innerhalb der letzten drei Jahre habe ich es nun mehrfach erlebt, dass mehr und mehr Zeit damit verbracht wird, Fehler in irgendwelchen Konfigurationsdateien zu suchen und wie die Bereitschaft und Möglichkeit, Konfigurationsdaten einfach anzupassen mehr und mehr schwindet. Wer sich schon einmal durch eine 20 A4-Seiten füllende XML-Konfiguration quälen musste, um die Ursache für plötzlich auftauchende „unerklärliche Seiteneffekte„ in einer Anwendung zu suchen, nur um dann nach Stunden entnervt fest zu stellen, dass ein kleiner Schreibfehler in einem Klassennamen schuld an der Misere war, der wünscht sich die ganze Flexibilität bald einmal ins Pfefferland.

Ist diese Form der Metaprogrammierung somit untauglich? Nein, aber ein paar Dinge sollten wir beachten:

	Weniger ist oft mehr. Es lohnt sich, kritisch zu hinterfragen, ob die mögliche Flexibilität überhaupt benötigt wird, und ob wir gewillt sind, den Preis für die erhöhte Komplexität zu bezahlen.
	Wenn wir uns in einem Bereich für datengetriebene Konfigurierbarkeit entscheiden, dann müssen wir sorgfältig darauf achten, dass wir das DRY-Prinzip strikte beachten, und es stets nur eine und wirklich nur eine tonangebende Quelle gibt. Insbesondere gilt es zu verhindern, dass wir das Gleiche mehrfach auf unterschiedliche Art und Weise sagen. Genauso wie parallele Klassenhierarchien in unseren Entwürfen ein Problem sind, gilt es, auf parallele Programm- und Konfigurationsstrukturen zu achten. Die Konfiguration soll den Programmcode ergänzen und ihn nicht nach äffen; das Gleiche gilt umgekehrt natürlich auch für den Programmcode.
	Wir sollten uns davor hüten, Ablauflogik in Konfigurationsdaten zu vergraben. Insbesondere das hierarchische Format von XML ist wenig geeignet, um Programmfluss mit Schleifen und Verzweigungen auszudrücken. Eine Little Language(LL) zum Beispiel auf der Basis von Ruby ist hierzu das bessere Mittel. Die LL eignet sich dabei auch sehr gut als tonangebende Quelle, auf deren Basis aktive Generatoren eine Vielzahl von Artefakten wie Code, Konfigurationen und sogar Dokumentation automatisch erstellen können.

Der unbedachte Einsatz von praktisch beliebig konfigurierbaren Abstraktionen, insbesondere auf der Basis von XML, führt unweigerlich ins Chaos und verhindert letztlich die ursprünglich angestrebte Flexibilität aufgrund der ungewollten Komplexität und unkontrollierbaren Seiteneffekten. Mit Augenmass und Bedacht eingesetzt ist Metaprogrammierung dagegen ein mächtiges Instrument für die Erstellung von flexibler und wartungsfreundlicher Software.

-nemo :-)

Über diesen Artikel diskutieren.

Zugriffe heute: 1 - gesamt: 5445.