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