Prinzipfrage: Wie hält man's mit OOP

[Olli]

Hi,

ich wollte mal folgendes fragen. Wenn ihr jetzt in der Situation wäret, ein Programm (mehrere Komponenten - aber nicht im Delphi-Sinne) neu schreiben zu müssen, welches soweit wie möglich Cross-Platform sein soll und jede Menge spezifischen Kram unterstützen muß, in dem aber bestimmte Layer austauschbar sein sollten (bspw. Kommunikation umstellen von Pipes auf Sockets oder DCOM nur durch das Austauschen einer Klasse und Neukompilieren) - 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.

Wie seht ihr das? Könntet ihr für beide Varianten (prozedural vs. OOP) Gründe nennen, die jeweils eurem Gusto entsprechen (also wenn ihr für OOP seid, dann eben für OOP, ansonsten für prozedural).


Danke!

[alzaimar]

Ich frickle seit 26 Jahren herum und kann eins dazu beisteuern:

Wenn es schnell gehen soll (eben rum-G-E-F-R-I-C-K-L-E), dann prozedural (weil ich damit groß geworden bin).
Soll es nachhaltig, robust, austauschbar, wohldefiniert sein, dann OOP.

Wenn ein alter Hase auf prozedurale Konzepte pocht, dann soll er Landschaftsgärtnter werden, wobei selbst dort OOP und UML sinnvoll sind.
Hmm. Ah: Waldschrat.. Neee, auch dort ist der OOP-Ansatz effizienter.. Hmm... Ah, ich habs: Er soll 'Ewiggestriger' werden.
Hups. Isser ja schon. :mrgreen:

Noch ein Killerargument: Wenn selbst Microsoft (die immer von Gestern sind) dot.Net pusht, dann sollte man sich vom API-Ansatz einfach verabschieden. Und wenn selbst das nicht greift, hab ich noch eine Alternative für die berufliche Zukunft des alten Hasen: Osterhase. :twisted:

[Dax]

Ich würde in dem Fall auf jeden Fall OOP benutzen, für solche Fälle ist diese Art zu programmieren doch geradezu geschaffen. Um bei deinem Beispiel des Austaschs der Kommunikationsschicht zu bleiben (hier als C#-Code), fiele mir OOP-mäßig sofort das nötige ein:

Code:

interface IChannel {
  void SendString(string s);
  string ReceiveString();
  void WaitFor(int timeOut);
}

Dieses Interface würde ich für jede Art der Kommunikation implementieren und hätte ruck-zuck eine sofort austauschbare Kommunikationsschicht :)

Prozedural wäre das nicht nur viel schwieriger zu lösen, sondern dazu noch fehleranfälliger, weniger deskriptiv und (sucht's euch aus). Codeblöcke im Namensformat (z.B.) Channel_Method müssten x-fach geladen und ersetzt werden, und wenn es bei einem nicht klappt, geht eventuell nicht mal alles hoch... Was man bei dem OOP-Ansatz nicht hat, dort könnte der Konstruktor eine Exception werfen und alles wär gut. Gerade solche Situationen (viele Methode, die unabhängig voneinander existieren, aber im Grunde zusammengehören) haben bei mir schon häufig sehr schwer zu findende Fehler produziert.

[Christian Seehase]

Moin Olli,

eigentlich bin ich ja auch ein Freund der OOP, aber:
Wenn das Ganze Cross-Platform-tauglich werden soll, halte ich doch den prozeduralen Ansatz für sinnvoll.

Begründung:
Je komplexer die verwendeten Sprachelemente sind, umso grösser ist auch die Chance, dass sie, teilweise sehr versteckte, Bugs enthalten. Diese könnten/dürften dann von Plattform zu Plattform auch noch unterschiedlich sein.
Dieser Punkt dürfte bei den doch sehr viel einfacher gestrickten prozeduralen Sprachelemente, vergleichsweise, nahezu entfallen.
Ausserdem müsste man beim OOP-Ansatz sehr viel mehr darauf achten nur solche Sprachfeatures zu verwenden, die auch auf allen Plattformen identisch zur Verfügung stehen, da ansonsten der Wartungsaufwand für verschiedene Versionen anwachsen wird.
Auch diese Problematik dürfte sich beim prozeduralen Ansatz kaum ergeben.
Das gilt umsomehr, als das ja eventuell noch eine Plattform hinzukommen kann, bei denen die Möglichkeiten noch gar nicht bekannt sind.
Je simpler die verwendeten Features sind, umso leichter dürfte das Programm zu portieren sein.

Klar, der Aufwand ist erst einmal höher, aber der Stabilität, und Portier- und Wartbarkeit dürfte es zugute kommen.
Um es mal etwas krass zu sagen:
Auch in Assembler kann man strukturiert programmieren, es erfordert nur ein wenig mehr Selbstdisziplin, aber die setze ich einfach mal voraus.

[boserPascal]

Guten Abend!

Weil ihr schon mal dabei seid, habt ihr Erfahrungen mit solchen Bibliotheken wie QTLib oder ACE? Beispielsweise ACE erzeugt ja einen gewissen nicht unbeachtlichen Mehraufwand, mit QTLib hab ich noch nicht gearbeitet. Lohnt sich aber dieser Aufwand nur für die Partabilität? Insbesondere wenn man bedenkt, dass man eigentlich maximal für 2 Systeme entwickelt (Windows/Linux).

Um zur Ausgangsfrage aber zurück zu kommen. Als alter C Programmierer, konnt ich mit dem Umstieg auf C++ viel schneller, einfacher und sicherer Anwendungen erstellen. Ich würd jetzt nur noch mich auf prozeduale Programmierung beschränken, falls es nicht anders zu lösen geht. Das bezieht sich jetzt auf technische Beschränkheit, da sich jedes Problem Objektorientiert lösen lässt.

Falls sich jemand mit oberen Punkt schon mal beschäftigt hat, würd ich gerne mal seine Meinung/Erfahrung dazu wissen.

Gruß Stefan!

[negaH]

Nimm das womit du glücklich werden kannst. Kein Scherz.
Ob du ein Problem procedural oder per OOP löst ist dem binärem Code und wohl auch dem Kunde piep egal. Gelöst ist gelöst.
Davon abgesehen weiß ich das du beides perfekt beherrscht. Ergo stellt sich nur eine einzige Frage für dich:
Was ist das beste Werkzeug um deine Aufgabenstellung zu lösen ?

Anders ausgedrückt: man kann per OOP so schlecht programmieren das es schlechter als eine Prozedurale Lösung sein wird.

Ich mische generell OOP und Prozedurale Programmierung, nutze also beide Welten in einem Produkt. Warum auch nicht ?
OOP fürs GUI auf alle Fälle, par Controls zu platzieren geht mit RAD und OOP noch am effizientesten.
Wichtige Funktionen aber, zb. mathematische Berechnungen oä. sind meistens Prozedural, auch wenn sie oft Methoden einer Klasse sein können. Ein weiteres Kriterium pro OOP ist die Frage nach einer sauber strukturierten Schnittstelle. Falls sich die Problemstellung sauber abstrahieren und in einzelne Aufgaben zerlegen lässt dann kann man meistens sehr gut per OOP diese Schnittstelle aufbauen. Aber dazu muß man meistens schon von Anfang an wissen was am Ende rauskommen soll. Oft ist dies nicht der Fall und so designt man ein aufwendiges OOP Konzept mit großer Klassenhierarchie die am Ende durch die geänderten Forderungen der Kunden quasi eingestampft werden muß. Sowas dann aus Zeitgründen irgendwie zurechtzubiegen geht einmal aber nicht zweimal.

Wie gesagt: OOP nicht in jedem Fall, jede andere Meinung grenzt an Fanatismus und berücksichtig nicht den Fakt das OOP nur eine abgewandelte Form der Prozeduralen Programmierung darstellt. Man kann ohne weiteres auch prozedural so programmieren das man Features der OOP anwenden kann. OOP ist nur ein Sprachfeature.
Aber OOP auf alle Fälle wenn's um GUI, Druckformulare, Datenbanken etc.pp. geht. Aber auch weil das fertige Komponenten sind die Zeit einsparen. Viele andere Teilprobleme lassen sich prozedural viel effektiver lösen. Zb. eine Komponnete für eine FFT oä. wäre kontraproduktiv.

Hm, naja soviel wird mein Pamphlet dir wohl nicht helfen, oder ;)
Letzendlich kann dir keiner die Entscheidung abnehmen. Ich würde auch berücksichtigen welche Leute du im Team hast. Sind es erfahrene OOP'ler dann OOP, kommen sie prozedural effektiver zum Ziel dann halt prozedural.
Ich persönlich zerlege erstmal das Problem immer weiter in Einzelteile. Dann erkenne ich sehr schnell ob sich viele der Teilprobleme gleichen, also ob OOP überhaupt einen Zeitvorteil bringen kann. Anders ausgedrückt: wenn ich das Problem in 100 verschiedene Teilaufgaben zerlegt habe, und alle verschieden sind, dann prozedural. Sollten sich viele der Teilaufgaben ähneln dann OOP da man so gleiche Aufgaben mit gemeinsammen Code vereinfachen und zeitlich effizienter lösen kann.
Das kann, und wird meistens dazu führen das man einen Mischcode produziert. Highlevel alles OOP und Lowlevel gekapselt in Methoden die prozeduralen Arbeitstiere.
Aber auf Teufel komm raus OOP wäre falsch. Das bescherrt uns dann solche Komponenten und Bibliothleken bei denen 100'erte Klassen enthalten sind die letzendlich nur eine einzigste Aufgabe lösen die eventuell mit 100 Zeilen in einer Prozedure auch erschlagen wäre.

[edit]
Und natürlich stimme ich auch Christian's Meinung zu. Meine Hobbyprojekte die ich mit C für MCUs programmiere sind generell Prozedural. Nur so ist es heutzutage mit den freien/kostengünstigen Werkzeugen möglich einen Source von einem AVR oder PIC auf einen ARM zu portieren. Arbeitet man selbstdiszipliniert und nicht allzu Hardwarenah (Assembler) dann hat man zb. einen FAT16 Treiber für SD Karten in 30 Minuten auf einen ARM portiert.

Ach und komplexe Datenstrukturen über die man wiederholte und komplizierte Gesamtberechnungen durchführen muß, programmiere ich am liebsten per OOP. Das hat den Grund das durch die Strukturierung der komplexen Daten in Klassen eine Abstraktion der auf diese Daten anzuwendenden Berechnungen stattfindet. Durch diese OOP Datenstrukturen werden also die Probleme mit den komplexen Berechnungen vereinfacht, bzw. überhaupt erstmal ein Lösungsweg sichtbar. Besonderst wenn man von Anfang an weiß das diese Berechnungen in Zukunft noch durch andere ergänzt werden sollen.
[/edit]

Gruß Hagen

[boserPascal]

Das es Quatsch ist jede Funktion in eine eigene Klasse zu stopfen ist prinzipiell richtig. Aber Objektorientiert heißt ja nicht nur Klassen aufzubauen. Beispielsweise in C++ werden durch Namensräume getrennte Bereiche geschaffen um Mehrdeutigkeiten und daraus resultierende Fehlfunktionen zu vermeiden.

[Luckie]

Units in Delphi sind auch nichts anderes als Namensräume. ;)

[Olli]

Zitat:

Zitat von Luckie

Units in Delphi sind auch nichts anderes als Namensräume. ;)

Nur daß sie in C++ auch modulübergreifend sind.

Ich lese mit und werde morgen mal antworten. Bin im Moment ein wenig beschäftigt.

[Chewie]

Grundsätzlich bietet sich für eine Bibliothekslösung ein objektorientierter Ansatz an.

Aber (großes aber): Die Frage ist, wie auf die Bibliothek zugegriffen werden soll. Bleibt man bei einer Sprache bzw. bei einem Framework, gibt es da sehr gute Wege. Will man aber eine weite Zahl von Plattformen und Programmiersprachen unterstützen, wird es sehr eng mit einer streng objektorienten Schnittstelle. Beispiel: Auf eine C-DLL kann ich mit fast jeder Programmiersprache zugreifen, bei C++ wird schon sehr schwierig. Und sowas wie COM ist halt schon wieder Windows-spezifisch.

Aber (nochmals ;) ): Objektorientierung ist ja auch mit einer Sprache möglich, die mir dabei nicht hilft. Denn was ist Objektorientierung eigentlich? Eigentlich doch nur die Idee, dass ich bestimmte Datenstrukturen hab, die alle mehrmals vorkommen können, einen jeweils eigenen Zustand haben können und ich kann Nachrichten an diese schicken, die eine Änderung des Zustands des Objektes selbst (und andere Objekte) auslösen können. Bei der Realiserung hilft mir eine objektorientiere Sprache natürlich ungemein, ich kann aber auch ohne eine solche objektorientiert programmieren.

Konkretes Beispiel: Nehmen wir eine Komponente namens SimpleStupidComponent. Diese bietet die Operationen Op1, Op2 und Op3 sowie die Eigenschafften Prop1 und Prop2. Von der Idee her sind folgende Modellierungen gleich:

Delphi-Quellcode:

SimpleStupidComponent = class
  Prop1, Prop2: SomeType;
  procedure Op1;
  procedure Op2;
  procedure Op3;
end;

Delphi-Quellcode:

SimpleStupidComponent = record
  Prop1, Prop2: SomeType;
end;

procedure SimpleStupidComponent_Op1;
procedure SimpleStupidComponent_Op2;
procedure SimpleStupidComponent_Op3;

Die erste Modellierung ist natürlich komfortabler und lässt eine Vielzahl der Prüfungen bereits vom Compiler erledigen, während die zweite Lösung sehr viel Aufmerksamkeit des Programmiers fordert, aber objektorientiert sind beide Lösungen. Die zweite Lösungen lässt sich allerdings problemlos in eine Schnittstelle packen, die von nahezu jeder Programmiersprache verwendet werden kann.

[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? :stupid:

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:

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

[MaBuSE]

Zitat:

Zitat von QuickAndDirty

...seit dem mache ich keine QuickAndDirty(mein Name) Lösungen mehr egal wie klein das Programm auch sein mag.

Man kann auch in OOP QuickAndDirty programmieren und man kann auch mit prozeduralem Ansatz sauber strukturiert programmieren. Das hat nichts mit dem OOP Ansatz zu tun, sondern nur mit der eigenen Struktur und Disziplin.

[negaH]

Zitat:

Ich denke in Bezug auf Erweiterbarkeit ist OOP eigentlich besser.

Nur oberflächlich betrachtet stimmt dies. Ich kann dir Beispiele nennen bei denen die "Erweiterbarkeit" von Klassen auf Grund der Regeln der OOP dazu führen musst das Monster-Klassen entstehen. Also Klassen mit über 300 Methoden. Das ist kontraproduktiv und eben nicht erweiterbar. Denn bei jeder Änderung wird das komplete Objekt verändert, was aber wenn das eine Basis Klasse ist und durch die Änderungen defakto alle abhängigen Klassen ständig neu kompliert werden müssen ? Prozedural hätte man einfach ein neue Prozedure in die Unit oder eine andere Reingepackt. Hauptsache diese Prozedure benutzt die gleichen Scnittstellen wie alle anderen Prozeduren.

Wie gesagt, erstmal soll uns die OOP Arbeit einsparen, und zwar indem man mit ihr ein identisches Problem nicht mehrmals prozedural löst sondern einmalig als Klasse zusammenfasst und wiederverwendet für andere Klassen. Man reduziert also die Komplexität des Problems durch die OOP und damit die Anzahl an Sourcezeilen. Wenn also ein Projekt per OOP mehr Sourcezeilen benötigt als Prozedural dann stimmt da was nicht vom Konzept her. Natürlich alles aus der Sichtweise heraus das wir die freie Entscheidnung überhaupt haben. Oft mß man per OOP oder prozedual programimieren weil man nicht die Manpower hat, nicht die richtigen Werkzeuge, weil es hoch-portabel belieben muß etc.pp.

Gruß Hagen

[MaBuSE]

Zitat:

Zitat von negaH

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.

Da ist was wahres drann.

Ich kenne einen Entwickler, der sollte ein einfaches kleines OOP Programm schreiben.
In dem Programm sind alle Techniken, die so gelehrt werden verwirklich.
Das Programm besteht aus einer kleinen GUI. In der GUI ist alles gegen Interfaces programmiert.
Sämtliche Objekte werden aus einer anderen Assebly mit sogenannten Factories erzeugt.
In einer anderen Assembly werden dann die Objekte implementiert. Im Hintergrund ist ein relativ großes Objektmodel entstanden, da jede Eventualität versucht wurde zu berücksichtigen. Es wurde ein "GrundObjekt" geschrieben, davon wurde ein etwas spezialisierteres Objekt abgeleitet, davon wieder eins und dann irgendwann das Objekt welches benutzt werden soll. Es entsteht der Eindruck es wurde nur des Ableitens Willen Abgeleitet, da die Objektebenen dazwischen nicht verwendet werden.
Bei der Gelegenheit wurde dann noch die ELIB (MS Enterprise Lib) verwendet und um eigene Funktionalitäten erweitert.
Die Anwendung ist eigentlich relativ klein, aber der komplette Quellcode ist rießig.
(Der Speicherverbrauch zur Laufzeit leider auch)
Das Programm wird von den Benutzern nur ungern eingesetzt, da es sehr schwerfällig, Speicherintensiv und langsam ist.

Was will ich damit sagen:
Man kann es treiben und man kann es übertreiben.

An Stellen wo es Sinn macht, sollte man die bekannten Techniken (OOP, MultiTier, Patterns, ...) verwenden.
Aber man sollte nicht nur der Technik Willen die Technik verwenden.

Wenn die Technik einen Nutzen verspricht, dann sollte man sie verwenden.
Wenn die Technik mehr Aufwand als Nutzen bringt, sollte man es überdenken.

[DeddyH]

@MaBuSE: Dein Beispiel erinnert mich irgendwie an die Hammer-Factory :zwinker:

[MaBuSE]

Zitat:

Zitat von DeddyH

@MaBuSE: Dein Beispiel erinnert mich irgendwie an die Hammer-Factory :zwinker:

Cool, das kannte ich ja noch gar nicht. Ich werde es mal an denjenigen weiterleiten :mrgreen:

[Olli]

Hi,

ich bedanke mich erstmal bei allen Diskussionsteilnehmern.

Der "alte Hase" ist leider nicht sonderlich gut in OOP, der Rest des Teams aber eigentlich schon. Prinzipiell hätte ich ja auch nichts dagegen, wenn das Interface nach außen funktional gestaltet wäre und statt Instanzen halt Handles benutzt (die dann intern auf Instanzen mappen :zwinker:).

Eigentlich bin ich inzwischen sogar entschlossener als zuvor es OOP zu machen. Ansonsten würden wir es später bereuen.


Danke nochmals.

[Hansa]

OOP-Anteile bei mir (grob geschätzt) :

TP 5.0 : 0 %
TP 5.5 : 2 %
BP 7.0 : 10 %
usw.

Delphi : nicht OOP-Anteil : ca. 5 %

OOP ist aber auch nicht einfach nur ein Schlagwort. IMHO müsste die Frage aber eher so lauten : "Welche triftigen Gründe gibt es, etwas nicht gleich mit OOP zu machen ?".

[MaBuSE]

Zitat:

Zitat von Hansa

OOP ist aber auch nicht einfach nur ein Schlagwort.

Was ist denn für Dich OOP?

Wenn jemand ein TForm benutzt und dort einen TButton benutzt um dann sein Programm auszuführen, was wiederum prozedural aufgebaut ist, nenne ich nicht unbedingt OOP.
Wenn jemand eigene Klassen baut, in denen alle Methoden static sind (class procedure), um sie dann wie normale Prozeduren aufzurufen, nenne ich das auch nicht unbedingt OOP.
Wenn jemand in C# einen string verwendet oder einen Integer, so ist das für mich auch kein OOP, obwohl der Integer ja ein Objekt ist.

[Hansa]

Zitat:

Zitat von MaBuSE

..nenne ich das auch nicht unbedingt OOP.

Ich auch nicht. Bei mir fängts mit Form-Inheritance an. Habe dementsprechend nur 2 Forms, die tatsächlich TForms sind (für Ein- und Ausgabe). Infolgedessen befinden sich neu eingeführte Variablen und Methoden vornehmlich in der protected-Sektion der Deklarationen. Es sollen eben immer nur neue Sachen dazukommen, die alten aber auch benutzt werden können. Infolgedessen ist auch oft override zu finden und in den Prozedur-Rümpfen inherited. Bei den Komponenten gehts dann weiter. Habe da einen ganzen Satz eigener, überwiegend von TEdit abgeleitet, um nicht jede Falscheingabe behandeln zu müssen. Die geht erst gar nicht. Rein prozedural bleibt wirklich nur eine Unit übrig die solche Funktionen/Prozeduren enthält : netto, brutto, lb, rb, zentriert usw.

[Olli]

Zitat:

Zitat von MaBuSE

Wenn jemand in C# einen string verwendet oder einen Integer, so ist das für mich auch kein OOP, obwohl der Integer ja ein Objekt ist.

Das ist übrigens das putzige an C++. Formal ist ein Integer kein Objekt, aber defacto schon, weil man im Grunde jeden Aspekt eines Integers in einer eigenen Klasse nachbauen kann.