Show description

Zunaehst ein Fenster mit Hilfe der bereits vorhandenen Routine offnen und als zweiten Sehritt zusatzlieh den Fensternamen ausgeben. Die letzte Alternative ist zweifelsohne die interessanteste. Sie ermoglieht die weitestgehende Nutzung bereits vorhandener Funktionalitat, denn die Routinen des neuen Fenstersystems implementieren nur noeh die neuen Eigensehaften (also hier den Fensternamen), greifen ansonsten aber auf bereits 30 2 Warnm objektorientierte Programmiernng? Vorhandenes zuruck. 1m Idealfall wird jegliche Doppelimplementierung von Funktionalitat vermieden.

1, das unter Solaris-Betriebssystemen lauft. x Der GroBteil aller Programme und Beispiele des Buehes sind mit diesen Cund sieher aueh mit den meisten anderen) Systemen unverandert tibersetzbar. B. x vorhanden etc. Was keinen Platz mehr gefunden hat 9 Bei der Behandlung von Sprachelementen, die nicht von allen Compilern unterstiitzt werden, weisen wir explizit darauf hin. Wenn es eine Mbglichkeit gibt, das fehlende Sprachrnittel zu simulieren2 , geben wir den notwendigen Code an. Ebenso weisen wir darauf hin, wenn Sprachrnittel von den Compilerherstellern unterschiedlich implementiert sind.

Wir zeigen an Hand von Beispielen aus der C-Praxis, wie einige alltägliche Probleme und Fehlerquellen traditioneller Programmierung mit Hilfe objektorientierter Konzepte gelöst bzw. ganz vermieden werden können. Traditionelle Programmerstellung In der Mitte der 90er Jahre hinkt die Softwareerzeugung um mindestens zwei Generationen hinter den Möglichkeiten der Hardware hinterher. Es zeigt sich mehr und mehr, daß große Softwarevorhaben mit konventionellen Entwicklungstechniken nicht mehr zu realisieren sind: Moderne Prozessoren erlauben größere und komplexere Programmsysteme, mehr und mehr Menschen werden Computer und die dazugehörigen Programme nutzen wollen oder müssen.