Zitat:
man kann per
OOP so schlecht programmieren das es schlechter als eine Prozedurale Lösung sein wird.
Soviel nämlich auch zum "Rumgefrickle". Das kann man objektorientiert noch viel schlimmer machen als prozedural. Oftmals hat man bei der Arbeit eine Software, die "gewachsen" ist. Das kann bei
OOP viel katastrophaler werden als bei prozeduraler Programmierung - aber andererseits, gerade wenn man, wie in diesem Fall der Fragesteller, die Möglichkeit hat, eine Anwendung komplett neu zu designen, sollte man auch
OOP verwenden. Wenn ein gutes Konzept dahintersteht, wird es ab einer gewissen Größe wesentlich übersichtlicher als eine Sammlung von Funktionen.
Aber dann muss man sich auch im Klaren sein, was
OOP bedeutet.
OOP bedeutet nicht, Klassen zu verwenden und keine "globalen" Funktionen mehr.
OOP ist im Endeffekt ein Konzept, Code modular aufzubauen, mit einer mehr oder weniger datenzentrischen Sicht, wiederverwendbar, leicht zu verstehen usw.
Prozeduren sind... Code-Module, die wiederverwendbar sind?
Der Ansatz der beiden Konzepte geht im Endeffekt in eine vergleichbare Richtung, und man kann nicht einfach sagen, dass man bei prozeduraler Programmierung keine Wiederverwendbarkeit hat. Insofern ist es einfach so, dass man sich das Leben mit
OOP wesentlich leichter macht, soweit man sie benutzen kann. Aber zwingende Voraussetzung für moderne Software ist sie nicht. Es ist nur so, dass man sich mit einer objektorientierten Sprache soviel weniger um Kleinigkeiten kümmern muss, und das ist der eigentliche Knackpunkt. Typisches Beispiel dafür ist RAII. In C darf ich Fehlerbehandlung von Hand machen, Rückgabewerte prüfen, alles aufräumen je nach Bedarf usw. In C++ erzeuge ich ein Objekt, die Fehlerbehandlung wird von Exceptions übernommen und das Objekt räumt sich am Ende von selbst weg. Egal wo ich ausgestiegen bin, und egal ob erfolgreich, per Rückgabewert oder per
Exception. Das ist auch eines der wenigen Features, die ich in C# vermisse (using ist nicht ganz so mächtig
).
Das alles im Hinterkopf, spricht nichts dagegen, auch in einer
OOP-Umgebung prozedurale Anteile zu verwenden. Im Endeffekt programmiert innerhalb einer Klasse doch auch prozedural. Gut, die Funktionen sind alle in einer Art Namensraum, der Klasse, zusammengefasst, und anstatt dass man ihnen die Daten in Form eines Zeigers explizit mitgibt, bekommen sie diesen Zeiger als this oder Self implizit mit. So groß ist der Unterschied da gar nicht. Erst wenn auch noch Polymorphismus und ähnliches dazu kommt, sieht man mit einer rein prozeduralen Sprache alt aus - aber selbst da kann man Prozeduren verwenden.
Zitat:
mit QTLib hab ich noch nicht gearbeitet. Lohnt sich aber dieser Aufwand nur für die Partabilität
Wir benutzen Qt für die "großen" Anwendungen (also solche, die auf einem Desktop/Server-
OS à la Windows, Linux, MacOS X laufen) und da ich hier gezwungen bin, mit C++ zu arbeiten, möchte ich Qt nicht mehr missen. Es ist sowohl für die
GUI als auch für alles dahinter bzw. auf Serverseite eine sehr mächtige Bibliothek, die fast alle wichtigen Features der Betriebssysteme über eine einheitliche Schnittstelle zur Verfügung stellt. Manchmal stößt man dann an diese Geschichte mit dem kleinsten gemeinsamen Nenner, aber das betrifft im wesentlichen
GUI-Klassen. Der zusätzlich "Aufwand" ist eher gering, im Gegenteil, ich finde, man arbeitet sehr viel schneller als ohne Qt (für Basisfunktionen hätte man ja noch boost, aber das sind mehr zusätzliche Sprachfeatures als eine umfangreiche Bibliothek), und man bekommt die Portabilität gratis dazu. Hier und da gespickt mit kleinen Portionen plattformspezifischem Code, kann man auch allerneueste
OS-Funktionen benutzen, ohne die Portabilität zu verlieren. Der Haken liegt im Preis, aber das ist ok, wenn man kommerziell entwickelt. Dafür ist das ganze dann auch brav in Visual Studio integriert. Und alles schön objektorientiert (manchmal extrem lästig *g*, aber insgesamt angenehm zu verwenden). Ab einem gewissen Umfang wäre das prozedural zwar noch möglich, aber einfach nicht mehr schön.
Insofern mein Fazit:
OOP. Prozeduren, wo sie nötig oder sinnvoll sind.