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.