"C++ is a language monster that requires coding patterns to tame its monstrosity."
[Pree, 1994]
Die erste Art der Entwurfsmuster, die hier vorgestellt werden sollen, sind die sogenannten coding patterns von James Coplien( [Coplien, 1995b] und [Pree, 1994].) Synonyme für coding patterns sind style guidelines und coding conventions . Bei den coding patterns handelt es sich um Richtlinien oder Wegweiser für guten Programmcode in objektorientierten Programmiersprachen, also Wegweiser für gute Programmierung auf der Ebene des Quellcodes. James Coplien beschränkt sich aber in der Regel auf Beispiele in der Programmiersprache C++, und das wohl aus gutem Grund, wie das Zitat oben überdeutlich zu vermitteln versucht. Bei den coding patterns handelt es sich um die niedrigste Ebene der publizierten Entwurfsmuster. Nach Wolfgang Pree [Pree, 1994, S. 73] haben die coding patterns die folgenden Ziele:
Die coding patterns ergänzen die formale Sprachspezifikation der Programmiersprachen, die in C++ sehr viel Spielraum für schlechte Stile und Angewohnheiten läßt, um semiformale Stilrichtlinien. Diese sollen zum einen, schlechte Programmierstile vermeiden, zum Beispiel durch Regeln für die Strukturierung (pretty printing) oder durch ein durchgängiges System für die Benennung von Variablen (siehe Beispiel 1). Zum anderen können, durch Richtlinien für die Codierung, typische Compiler- und Laufzeitfehler vermieden werden (siehe Beispiel 2). Die Veröffentlichung von Coplien, die zunächst wie ein weiteres Lehrbuch für die Programmiersprache C++ aussieht, ist auf den zweiten Blick eine Mustersammlung für den guten und sicheren Programmierstil. Was bei anderen Autoren nur verstreut als Bemerkung oder Ratschlag auftaucht, wird hier zum Systematischen Schreibstil. Es gleicht damit Lehrdefizite aus und vermittelt Erfahrungswissen über die Verwendung dieser speziellen Programmiersprache. Dabei sind die coding patterns so spezialisiert, daß sie praktisch nur auf C++ angewendet werden können. Zur Erläuterung der coding patterns folgen nun zwei Beispiele die in der Praxis schon manchem Anfänger Probleme bereitet haben.
Konventionen zur Namensvergabe für Funktionen und Variablen sind für größere Softwareprojekte äußerst wichtig. Ein Grund dafür ist die große Anzahl an Mitarbeitern in solchen Projekten. Würde jeder eigene Namen nach Gutdünken vergeben, so wären die Programmteile für andere Personen nur noch schlecht lesbar. Des weiteren ist zu beachten, daß beim Zusammenbinden von vielen Programmodulen zusammen mit Bibliotheken, häufig Namensüberschneidungen auftreten würden. Allgemeine Vereinbarungen bezüglich der Namensvergabe würden die meisten genannten Probleme verhindern, mit Ausnahme bei gekauften Bibliotheken die sich nicht an die projektinterne Konvention halten können. Eine mögliche Namenskonvention wird am Beispiel des Framework ET++ in Abbildung 13 ausschnittsweise vorgestellt.
Abbildung 13: Namenskonventionen in ET++ [Pree, 1994]
James Coplien beschreibt in einem weiteren Entwurfsmuster die Grobstruktur, die eine C++ Klasse besitzen sollte, unter der Voraussetzung, daß Variablen ausschließlich statisch deklariert werden. Dazu definiert er die sogenannte kanonische Form der Klasse, die grundsätzlich folgende C++ Konstrukte fordert:
Im folgenden wird die Bedeutung der einzelnen Begriffe erläutert, wobei vermieden werden soll, zu sehr auf die C++ spezifischen Eigenheiten einzugehen. Für weitere Informationen über die Programmierung siehe auch [Stroustrup, 1992].
Der Standard-Konstruktor wird bei der Erzeugung eines neuen Objekts aufgerufen, sofern beim Aufruf keine Parameter angegeben werden. Konstruktoren haben die Aufgabe, die objektinternen Variablen zu initialisieren und Speicher für dynamische Objekte anzufordern. Genau hier liegt die Problematik bei C++. Wird der Standard-Konstruktor nicht explizit in der Klasse aufgeführt, so werden zwar die statischen Elemente eines Objekts korrekt vom Compiler initialisiert, bei dynamischen Objekten (über Zeiger) geschieht dies aber nicht. Ein Aspekt, der mitunter häufig vergessen wird. James Coplien fordert daher grundsätzlich die Implementierung eines expliziten Standard-Konstruktors, der dieses Problem beseitigt.
Mit dem Zuweisungsoperator (in C++ ist dies das Symbol = ) wird die korrekte Zuweisung der Elemente zweier Objekte vorgenommen. Abbildung 14 zeigt das Problem, das bei dynamischen Elementen mit Hilfe der automatischen Zuweisung auftritt.
Abbildunt 14: Problematik der Zuweisung dynamischer Objektelemente [Pree, 1995]
Der Destruktor einer Klasse hat zur Aufgabe, den belegten Speicher der Objekte dieser Klasse wieder freizugeben. Die Aufgabe der Speicherfreigabe wird in C++ nicht vom Compiler oder von einem Laufzeitsystem vorgenommen. Der Programmierer übernimmt selbst diesen Part und muß dafür sorgen, daß dynamisch angeforderter Speicher eines Objekts freigegeben wird. Ohne die explizite Angabe eines Destruktors beschränkt sich die Freigabe auf den statischen Speicher (Stack), was mit der Zeit zu einer Anhäufung von Datenmüll und somit zur Verkleinerung des freien Speichers führt.