Prinzipfrage: Wie hält man's mit OOP

[negaH]

super, und wenn man jetzt dein Posting chronologisch rückwärts betrachtet, dann weiß man welche Wurzeln die heutige OOP hat. Denn exakt mit solchen Konstrukten entstand die OOP aus der proceduralen Programmierung.
Es war quasi ein absolut logischer Gedanke das man die Datentypen um die Deklaration ihrer implemtierenden Funktionen erweiterte.

Gruß Hagen

[Robert Marquardt]

Die Frage ist wie der Austausch der Komponenten erfolgt. Sollten es DLLs sein (respektive shared objects), dann braucht man ein prozedurales API. Das bedingt natuerlich nicht das man die Teile der Applikation nicht mit OOP macht. Ein schmales API hat auch den Vorteil das man die Schnittstelle auf das Wesentliche reduziert und genau darueber nachdenkt was man braucht.

Satz war falsch.

[Tyrael Y.]

Ich finde beide Varianten haben ihre Berechtigung.
Einfache wiederverwendbare Funktionen, die nicht unbedingt Teil dieser einen Klasse sein müssen packe ich auch sehr gern in eine Prozedur/Funktion und lagere es aus.

In letzter Zeit gehe ich mehr und mehr dazu über Prozeduren/Funktionen in eine Klasse zu stecken und dort als Klassen-Funktion zu benutzen.
Diese Klassen beinhalten dann bei mir ausschliesslich Klassen-Funktionen, so daß es nicht möglich ist daraus Instanzen zu erstellen.

Mathematische Funktionen zB fasse ich dann so zu einer logischen Einheit zusammen und es können dann nie Konflikte entstehen, wenn ich irgendwo im Uses zwei Units habe die jeweils eine Funktion haben, die denselben Namen und dieselbe Parameterliste besitzen.

[OregonGhost]

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.

[alzaimar]

Bei OOP geht es ja nicht nur darum, eine Klasse zu basteln und den Parameter einer Prozedur als Instanznamen vorne ran zu bepseln (Foo(Bar) vs. Bar.Foo), sondern um die gesamte Sichtweise der API.

Die Win32-API ist ja zu verwenden, aber dot.NET ist irgendwie übersichtlicher, nachhaltiger und klarer strukturiert. Und DAS war nunmal die Ausgangsfrage, und nicht, ob ich in einer OOP-Umgebung auch mal Prozeduren schreiben soll, oder jeden Pups in eine Klasse packen muss (Dogmen sind der Tod der Kreativität). Das man in den einzelnen Modulen (Namespaces) durchaus prozedural rumfrickeln kann/sollte, steht doch gar nicht zur Debatte und ist imho -mit Ausnahme in der Lehre- sowieso gängige Praxis und auch praktikabel.

Die Diskussion, was nun automatisch besser ist (Proc vs. OOP) ist müßig, denn es kommt sowieso auf das Können an. Wenn ich aber von vorne herein etwas Neues auf die Beine stellen will, dann sollte ich doch -bitte schön- einen Ansatz wählen, der dem 21.Jahrhundert gerecht wird. Insofern finde ich die Bockigkeit von dem 'alten Hasen' eben etwas grenzdebil (außer er hat stichhaltige Argumente).

Klar, bei plattformübergreifenden Lösungen muss man erst mal den kleinsten gemeinsamen Nenner finden und bei einer Plattform, die OOP nur bedingt unterstützt, scheidet OOP nun mal aus. Aber das ist doch banal. Wenn ich mir die Frage schon stelle (OOP oder nicht OOP?), habe ich doch schon abgeklopft, das OOP im Prinzip ginge, oder nicht?

[mschaefer]

Mal knapp zu Cross-Platform:

Habe inzwischen erstaunlich gute Erfahrungen mit Delphi-Programmen unter Wine gemacht. Die native VCL scheint jedenfalls trotz vieler NETigkeiten so schnell nicht auszusterben. Den Weg über Wine findet man selbst bei Google-Earth für Linux wieder.

Grüße // Martin

[sh17]

Warum ist eigentlich Proc und OOP an der Plattform/Cross-Plattformfähigkeit festzumachen?

Nutzt man in dem Projekt nicht eine Sprache, die auf allen Zielplattformen vorhanden ist?

[QuickAndDirty]

Ich denke in Bezug auf Erweiterbarkeit ist OOP eigentlich besser.
Ich hab mal nen Auftrag für einen Assistenten gekriegt der auf grundlage einer Template Datei
einige kleine Erweiterungen an einer Arbeitsoberfläche vornehmen sollte. Sprich man konnte mal eben
ein Konto aus der Oberfläche enfternene oder andere hinzufügen, Andere Stammdaten anzeigen lassen und
so, er hat halt daraus eine Oberflächen Konfigurations Datei erstellt wie sie von unserer Anwendung
geladen wird. Das war für Händler gedacht die den Oberflächen Editor (quasi eine IDE ohne Prgagrammierung)
nicht bedienen konnten weil er zu viel wissen erfordert.
Ich dachte mir machs einfach Prozedural hatte das Dingen super schnell fertig programmiert....
Leider sollte ich es immer wieder erweitern irgendwann sollte es fast alles können wie der Editor selbst.
Der Code ist zu einem wahren Monster angewachsen, es ist verdammt schwer das ding zu erweitern glaubt es mir
seit dem mache ich keine QuickAndDirty(mein Name) Lösungen mehr egal wie klein das Programm auch sein mag.

[MaBuSE]

Zitat von Olli:

... - würdet ihr dort von vornherein OOP einsetzen oder nicht?
Ich persönlich würde es tun (allerdings nicht mit Delphi, hat aber diverse andere Gründe als meine üblichen). Ein Entwickler des Teams - ein alter Hase - würde allerdings ein Design mit guten alten Funktionen bevorzugen, was ich nun weder richtig nachvollziehen noch gutheißen kann/will...

Ich muß Hagen voll zustimmen.
Man kann mit OOP ein Projekt sehr sauber und offen strukturieren.
Das kann man aber auch mit einem prozeduralem Ansatz machen.

Genauso gut kann man mit OOP ein Projekt so chaotisch "zusammenfrickeln", das es unwartbar wird.
Natürlich kann man auch mit dem prozeduralem Ansatz unwartbare Projekte erzeugen.

Es kommt auf die Struktur der Anwendung und auf Eure Disziplin an.

Ich persönlich würde eine Mischung aus OOP und Prozeduren/Funktionen bevorzugen.

Die OOP eignet sich hervorragend um z.B. Funktionalitäten auszutauschen.
Z.B. gegen ein Interface programmieren und das Objekt dann austauschen, je nachdem wie Du die Kommunikation umstellen willst.

Es ist auch möglich das Dein alter Hase Proceduren schreibt, die Du dann in Deinem OOP verwendest.
Die Patterns der GoF "Farsade" und "Adapter" sollten Dir ja bekannt sein.

Ich persönlich würde aber ehr wie Du zu OOP tendieren.

[negaH]

Zitat:

Die Win32-API ist ja zu verwenden, aber dot.NET ist irgendwie übersichtlicher, nachhaltiger und klarer strukturiert.

Warum ist das so ? Warum konnte man per OOP die .NET Schnittstellen übersichtlicher struktureren als das Win32 API ?

Ganz einfach. Weil die Schnittstellen Anforderung an beide der Zugriff auf "Objekte" mit ähnlichen Eigenschaften implementiert. Wäre es nicht an diesem so würde eine OOP Schnittstelle nur dann Sinn machen wenn sie ansich standardisierte Objekte benutzt die auch in anderen Schnittstellen benutzt werden. Also kann man sagen

1.) OOP bringt immer dann einen Effekt wenn sich dadurch die Schnittstelle hierarisch vereinfachen/zusammenfassen lässt, zb. GUI/GDI usw. Objekte
2.) OOP auch dann wenn die Schnittstelle dadurch standardisiert wird, zb. COM/DCOM/CORBA usw.

Das sind meiner Meinung nach die beiden einzigsten Entscheidungspunkte warum man OOP benutzten sollte oder nicht. Denn letzendlich besteht das Ziel in der Anwendung der OOP nur darin schneller, besser mit weniger Fehlern zu Implementieren.
Diese primäre Liste kann man dann erwietern um sekundäre Punkte -> Welche Sprache, welche Features hat sie, wie portabel wäre der Source, wer arbeitet im Team, wieviel Zeit ist, welche Vorgaben hat man usw. usw. Diese Punkte werden erst dann wichtig wenn man obige 2 Punkte beantwortet hat. Denn es nützt nichts sich mit den anderen Fragen zu quälen wenn man noch nicht weiß ob per OOP überhaupt ein Nutzen für das Projekt entsteht. Keinen Nutzen habe ich wenn per OOP 30mal mehr Source anfällt, alles viel kompilizierter wird als es real ist, OOP soll vereinfachen.

Namensräume und solche Details sind Aufgabe der Programmiersprache, fast jede moderne Sprache kennt dieses Konzept, egal ob OOP oder prozedral, und ist damit kein Entscheidungskriterium.

Gruß hagen