OWL und MFC, Borland oder Microsoft?

Grundlagen der Rahmenwerke 

»Am Anfang war C... .« Mit dieser Feststellung habe ich die Diskussion der Programmiersprache C++ begonnen. Gleiches gilt aber auch für die Windows-Pro-  gramierung: Zu Anfang wurden fast alle Windows-Programme in C geschrieben. Auch die Windows-API (API steht für Application Programming Interface) ist nichts anderes als eine riesige Sammlung von C-Funktionen (die genaue Anzahl der Funktionen geht in die Hunderte), und zweifellos gibt es noch Tausende von Programmierern, die ihre Windows-Programme in C schreiben. irgendwann haben die Leute von Borland beschlossen, daß es einen einfacheren Weg zum Schreiben von Windows-Anwendungen geben muß (die Idee der Rahmenwerk-Programmierung geht nicht allein auf Borland zurück, doch Borland  war führend an der Verfolgung dieser Idee beteiligt). Ausgangspunkt war die Feststellung, daß die Windows-Programmierung sehr gut zu C++ und umgekehrt C++  sehr gut zur Windows-Programmierung paßte. So konnten durch die Erstellung von Klassen, die grundlegenden Aufgaben der Windows-Programmierung gekapselt, die Programmierung vereinfacht und die Produktivität gesteigert werden. Eine einmal erstellte Klasse, die zum Beispiel die Funktionalität eines Fensters  kapselt, kann wieder und wieder verwendet werden. Die »Rahmenwerk«-Revolution begann.  Doch habe ich bis jetzt noch gar nicht erklärt, was ein Rahmenwerk eigentlich ist. Ein Ramenwerk ist  ein Sammlung von Klassen, die durch die Kapseling häufig benutzer Programmiertechniken die Windows-Programmierung vereinfachen. Ramenwerke werden auch als Klassenbibliotheken bezeichnet.

Rahmenwerke können Sie objektorientierte Programmierung lehren 

Wenn Sie damit beginnen, dieses verrückte Spiel, das wir Windows-Programmie-rung nennen, ernsthaft zu betreiben, werden Sie irgendwann auch in den Quell-text ihrer Lieblings-Klassenbibliothek hineinspähen.  Früher oder später werden Sie wissen wollen, wie die Profis arbeiten, und die Quelltexte der OWL- und der VCL bieten sich dafür natürlich an.

Der MFC-Quellcode ist nicht unbedingt die beste Adresse, wenn man sich an professionellem objektorientierten Design erfreuen möchte.  MFC fehlt die Eleganz, die Abstraktheit und die Gesamtkonzeption, die ein erstklassiges Rahmenwerk auszeichnen.  Außerdem werden hin und wieder die OOP-Regeln verletzt.  MFC mag zwar die populärste Klassen-bibliothek sein, doch heißt das nicht, das sie - was OOP an-geht - auch die beste ist.

An einem Wochenende, wenn das Laub geharkt ist, das Haus einen neuen An-strich bekommen hat, die Wäsche gemacht ist, die Kinder bei der Großmutter sind und sie glauben, C++ gut im Griff zu haben, dann sollten Sie etwas Zeit inve-stieren, um in ihrer Klassenbibliothek zu schmökern.  Auf den ersten Blick kann das ganz schön verwirrend sein, doch nach einer Weile werden Sie anfangen zu verstehen, was die Entwickler da gemacht haben.  Strengen Sie sich nicht zu sehr an. Versuchen Sie die Dinge zu verstehen, die Ihre C++-Kenntnisse herausfordern, ohne sie zu übersteigen.  Heben Sie sich die komplizierteren Sachen für den näch-sten Monat auf.  Aber sehen Sie sich an, wie die Zugriffsbeschränkungen private, protected und publ i c eingesetzt werden.  Wie und wann werden i n 1 i ne-Funktionen verwendet?  Wie werden Dinge, die dem Anwender verborgen bleiben sollen, der Öffentlichkeit entzogen?  Wenn man sich eine gute C++-Klassenbibliothek genau ansieht, kann man sehr viel über C++ und objektorientiertes Programmieren lernen.
 
 

Der C++-Rahmenwerk-Krieg 

Rahmenwerke müssen in zwei Kategorien eingeteilt werden: die C++-Rahmen-werke und die VCL.  Von diesen werde ich zuerst die C++-Rahmenwerke und da-nach die VCL besprechen.  Für C++ gibt es tatsächlich nur zwei Rahmenwerke, die den Anforderungen der Praxis gewachsen sind, nämlich Borland's OWL und Microsoft's MFC.

Borlands Object-Windows-Bibliothek (OWL) 

Vor einigen Jahren übernahm Borland mit der OWL die Führerrolle unter den Klassenbibliotheken.  Am Anfang stand natürlich OWL 1. Diese erste Version war ein eigenständiges Produkt, bestimmt für die 3-Version von Borlands C++-Com-piler (eigentlich war die allererste OWL für Turbo Pascal entwickelt worden; spä-ter wurde sie dann in C++ umgeschrieben).  OWL 1 war ein gutes Rahmenwerk, doch wegen bestimmter gesetzlich geschützter Syntaxelemente und anderen Streitigkeiten wollte Borland diese Entwicklung nicht weiter verfolgen.  Dennoch hat Borland mit der OWL 1 der gesamten Windows-Entwicklergemeinde einen Dienst erwiesen - Rahmenwerke fanden mehr und mehr Beachtung.  OWL 1 war die erste Klassenbibliothek, die auf dem Markt Erfolg hatte (wenn es auch nicht die erste war, die jemals geschrieben wurde).

Nach OWL 1 kam OWL 2. Diese Klassenbibliothek war ein Meisterstück.  Sie ent-hielt viele der neuesten C++-Elemente - nicht weil sie neu waren, sondern weil sie sich als sinnvoll erwiesen.  Das Beste von allem war, daß Borland die OWL 2 in den Borland-C++-4-Compiler eingebunden hatte.  Von nun an gehörte die OWL als fester Bestandteil zum Borland-C++-Paket.  Die C++-Compiler von Borland waren schon immer die ersten, die neue C++-Elemente unterstützten, und die OWL 2 hat davon profitiert.  Die gesetzlich geschützte Syntax, die die OWL 1 noch plagte, wurde über Bord geworfen.  OWL 2 war durchgehend in Standard-C++ geschrie-ben, das mit jedem C++-Compiler übersetzt werden konnte - zumindest theore-tisch.  Die Sache war jedoch die, daß nur wenige Compiler die neuesten C++-Ele-mente implementiert hatten.  Deshalb wurde die OWL 2 typischerweise nur zusammen mit den Compilern von Borland verwendet.

Borland brachte eine Überarbeitung der OWL 2 unter dem Namen OWL 2.5 her-aus.  Größtenteils waren die Änderungen nur geringfügig, daß heißt, es wurde zur OWL 2 nicht viel hinzugefügt: einige Fehlerkorrekturen hier und da und ein paar neue Klassen.  Aber in einer Hinsicht war OWL 2.5 bedeutend: Ein neuer Satz von Klassen, der als OCF (Object Components Framework) bezeichnet wurde, unter-stützte nun die Verknüpfung und Einbettung von Objekten (OLE = Object Linking and Embedding).  Technisch gesehen, ist die OCF kein Teil der OWL.  Die beiden arbeiten wunderbar zusammen, doch kann OCF auch ohne die OWL verwendet werden.

Die neueste und beste Ausgabe der OWL trägt die Versionsnummer 5. Sie stellt eine bedeutende Steigerung gegenüber OWL 2.5 dar, insbesondere wegen der neuen Klassen, in denen die Win32-Standard-Steuerelemente gekapselt sind.  Die OCF wurde ebenfalls auf den neuesten Stand gebracht.

Die OWL hat beachtliche Stärken.  Sie ist ein architektonisches Wunderwerk, das offensichtlich von Anfang an sehr gut durchdacht wurde.  Ich möchte daher meine Bewunderung für Carl Quinn, Bruneau Babet und die anderen aus dem OWL-Team nicht verhehlen.  Die OWL macht vielfältigen und sinnvollen Gebrauch von OOP und hält sich auch an alle Regeln der objektorientierten Programmie-rung.  Ihr Abstraktionsniveau hält geschickt die Waage zwischen maximaler Lei-stungsfähigkeit und einfacher Einsetzbarkeit.  Und es gibt einen entscheidenden Vorteil gegenüber den Konkurrenten: die OWL kann sowohl in 16-Bit- als auch in 32-Bit-Programmen verwendet werden.  Borland hat sogar einige der 32-Bit-Stan-dard-Steuerelemente für die Verwendung in 16-Bit-Programmen emuliert.  Obwohl diese Emulationen nicht in allen Fällen perfekt sind, kann man sie verwenden, um auch 16-Bit-Programmen einen Hauch von Win95 zu verleihen.

Die OWL hat auch ihre Schwächen.  Ironischerweise ist es gerade eine der Stärken der OWL, die - nach Ansicht mancher Leute - zu einem Handicap wird.  Die OWL hat mit der Kapselung der Windows-Umgebung eine großartige Arbeit geleistet.  Der Grad der Kapselung hat aber zu einer Komplexität geführt, die es dem Anfän-ger manchmal schwer macht, sich zurechtzufinden.  Es braucht seine Zeit, um der Dinge Herr zu werden, das ist keine Frage.  Aber wenn Sie die OWL im Griff haben, dann können Sie sehr effizient Windows-Programme schreiben.

Die Microsoft-Foundation-Klassenbibliothek (MFC)

Irgendwann zwischen OWL 1 und OWL 2 wurde die Microsoft-Foundation-Klas-senbibliothek (MFC) geboren.  Die MFC ist Bestandteil des Visual-C++-Pakets von Microsoft.  Sie wird aber auch mit den Compilern von Symantec, Watcom und -unglaublich, aber wahr - Borland ausgeliefert (es können auch noch weitere sein).  Bezeichnenderweise hat Microsoft für die anderen Compiler-Bauer (Syman-tec und Watcom) nicht die neueste Version der MFC lizensiert.  Dennoch enthält Borland C++ 5.01 die zu dieser Zeit aktuelle MFC-Version 4.1 (die Version 4.2 er-schien kurz danach).

Man kann sagen, daß die MFC einen anderen Typ von Klassenbibliothek verkör-pert als die OWL.  Die MFC ist weniger abstrakt und liegt näher an der Windows-API.  Die Stärken der MFC liegen in drei Punkten: Zunächst ist der Umgang mit die-sem Rahmenwerk verhältnismäßig leicht zu erlernen Oeicht zu verstehen, ist keine der Windows-Klassenbibliotheken; aber bei der MFC geht es etwas schneller als bei der Konkurrenz).  Der Grund dafür findet sich vor allem im schwächeren Abstraktionsniveau.  Wenn Sie keine Erfahrung in der Windows-Programmierung

haben, werden Sie die MFC und die OWL wahrscheinlich als ähnlich schwierig empfinden.  Sind Sie hingegen mit C und der Windows-API schon vertraut, dann wird Ihnen der Umgang mit der MFC sicher leichter fallen als mit der OWL.

Eine weitere Stärke der MFC ist - zumindest für manche Programmierer - die Tat-sache, daß sie nur eine dünne Hülle um die Windows-API bildet.  Wieder gereicht dies vor allem den Windows-Programmierern zum Vorteil, die aus der C-Ecke kommen und nun mit der MFC in C++ programmieren wollen.  Sie werden sich beim Gebrauch der MFC gleich ein bißchen heimisch fühlen.

Schließlich hat die MFC den klaren Vorteil, daß sie von Microsoft kommt.  Werden neue Windows-Elemente und -Konzepte auf den Markt gebracht, ist die MFC, die erste Bibliothek, in der diese Elemente und Konzepte eingearbeitet sind.  Microsoft kann neue Technologien entwickeln, und sobald diese herauskommen, werden sie auch schon von der MFC unterstützt.  Aber das braucht uns nicht zu frustrieren!

Die MFC hat aber auch ihre Schwächen.  Der erste und wichtigste Kritikpunkt ist, daß die MFC nur eine dünne Hülle um die Windows-API ist. »Moment mal!«, wer-den Sie sagen, »eben hieß es noch, das sei eine der Stärken der MFC.« Stimmt, die-ser Punkt stellt aber ebenso eine Schwachstelle dar.  Manche Leute betrachten die enge Bindung an die API als Stärke, ich hingegen sehe darin eine Schwäche.  Die Idee, die hinter einer Klassenbibliothek steckt, ist doch die, den Anwender von den Dingen abzuschirmen, die er oder sie nicht zu wissen brauchen.  Dieses Kriterium erfüllt die MFC in vielen Fällen nicht.  Am besten bilden Sie sich dazu Ihre eigene Meinung.  Zu diesem Thema ist auch noch anzumerken, daß die MFC wenig Vorteil aus der objektorientierten Programmierung zieht.  Manchmal er-innert die MFC mehr an einen hastig implementiertem Haufen von Klassen (die nicht sehr gut miteinander kooperieren) als an ein von Grund auf geplantes und durchdachtes Rahmenwerk.

Ein weiteres mögliches Problem ist ferner, daß die neueste Version, die mit dem Visual-C++ 4-Compiler und höher ausgeliefert wird, eine reine 32-Bit-Version ist.  Um 16-Bit-Programme zu schreiben, können Sie zwar den im Paket enthaltenen Visual-C++-1.5-Compiler benutzen, doch werden Sie wahrscheinlich von der Ent-wicklungsumgebung, die Sie hier vorfinden, eher enttäuscht sein.

Und wer gewinnt? 

Ohne Frage ist die MFC weiter verbreitet als die OWL.  Mit dafür verantwortlich ist der Name Microsoft, den sowohl die MFC als auch der Visual-C++-Compiler tra-gen.  Es ist kein Geheimnis, daß Microsoft der ungekrönte König der Software-Industrie ist.  Es ist auch kein Geheimnis, daß Microsoft einen Einfluß auf den Markt besitzt, von dem andere Firmen nur träumen können.  Hinzu kommt die weit verbreitete Einstellung, daß man mit dem Kauf von Microsoft-Produkten zu-mindest nie ganz falsch liegt.

Ich bin der festen Überzeugung, daß die OWL die bessere Klassenbibliothek ist.  Kaum jemand, der intensiv mit beiden Produkten gearbeitet hat, wird darüber diskutieren wollen.  Dennoch ist heute die MFC das populärste C++-Rahmenwerk.  Es gibt viele Gründe dafür.  Einige davon habe ich bereits erwähnt.  Ein weiterer ist die in den letzten Jahren bei Borland zu beobachtende Konzeptionslosigkeit.  Manche Manager gehen lieber auf Nummer Sicher und kaufen - ohne auf Qualität zu achten - die Produkte des »großen M«.  Da kann man nur hoffen, daß uns diese Einstellung nicht eine Software-Industrie beschert, in der es keinen Wettbewerb mehr gibt.  Dieser Industriezweig braucht unbedingt Firmen wie Borland, die eine Entwicklung vorantreiben können.

Wie sieht die Zukunft der C++-Klassenbibliotheken aus?  Es ist müßig, darüber zu spekulieren.  Allerdings könnte es passieren, daß beide Klassenbibliotheken Verlierer sein werden - zugunsten der neuesten Entwicklung: den Komponenten.
 

Die Visual-Component-Bibliothek 

Man schrieb das Jahr 1995, als Borland ein neues, revolutionäres Produkt auf den Markt brachte: Delphi.  Es schlug sofort ein.  Mit Hilfe sogenannter Komponenten [ermöglicht Delphi die »schnelle Anwendungsentwicklung« (RAD = Rapid Applica-tion Development).  Komponenten sind Objekte, die in Formularen abgelegt wer-den und die man dann - über Eigenschaften, Methoden und Ereignisse - weiter bearbeiten kann.  Wenn Sie so wollen, ist das visuelle Programmierung.1

Das Konzept formularbasierter Programmierung wurde bekannt durch Micro-softs Visual Basic.  Anders als Visual Basic, verwendet Delphi aber eine Abwand-lung von Pascal als zugrundeliegende Programmiersprache.  Diese neue Sprache, Object Pascal, führte die objektorientierte Programmierung in Pascal ein.  In ge-wissem Sinne ist Pascal für Object Pascal dasselbe, was C für C++ ist.  Delphi und Object Pascal, das ist die Verheiratung objektorientierter und formularbasierter Programmierung.  Außerdem können Sie mit Delphi eigenständige Anwendungen erzeugen.  Echte Programme.  Programme, die keine DLL benötigen, um zu laufen; Programme, die kompiliert werden und nicht interpretiert; Programme, die um das Zehn- bis Hundertfache schneller sind als Visual-Basic-Programme.  Die Pro-grammierwelt war beeindruckt.

Delphi drückt Ihnen nicht einfach nur Object Pascal in die Hand und läßt Sie dann damit allein.  Es führte auch die Visual-Component-Bibliothek (VCL) ein.  Die VCL ist ein Rahmenwerk für die Windows-Programmierung in Object Pascal.  Doch ist sie nicht einfach mit der OWL oder der MFC vergleichbar.  Die VCL ist zwar ein Rahmenwerk, aber mit einem völlig anderen Kern.  Der wesentliche Unterschied ist das Konzept der Eigenschaften, Methoden und Ereignisse.

Sie werden sich vielleicht fragen, warum ich soviel über Delphi erzähle.  Der Grund hierfür ist ganz einfach, denn genau die gleiche VCL, die das Herz von Delphi darstellt, bildet auch das Herzstück von C++Builder.  Das könnte ein klei-ner Schock für Sie sein.  Haben Sie bisher mit C++ gearbeitet, werden Sie sich am Kopf kratzen und sich fragen, wie das funktioniert.  Kommen Sie jedoch aus der Pascal-Gemeinde, dann dürfte Ihr Gesicht nun von einem breiten Grinsen durch-zogen sein.  Vielleicht sind Sie aber auch völlig unbeeindruckt.  Am Ende spielt das gar keine Rolle; Hauptsache es funktioniert.