Hallo,
Modellieren wir doch einfach mal ein Kraftfahrzeug als Klasse...
Das finde ich ein ziemlich gutes Beispiel. Es beinhaltet auch die wesentlichen Merkmale der Objektorientierung Kapselung, Vererbung, Polymorphie, Abstraktion.
Aber du hattest ja gemeint, dass die prozedurale Denkweise mehr der natürlichen Denkweise des Menschen entspricht. Wie würde man also "prozedural" ein Auto programmieren?
Dann muss ich modularisieren: Dann bereite ich den Aperitif, den Salat, die Suppe, den Hauptgang, das Dessert und den Kaffee separat (in einzelnen Modulen) vor, die ich geeignet koordinieren muss. Für jedes einzelne Modul gilt aber wieder das vorher Gesagte: Erst sicherstellen, dass auch alles da ist, was ich brauche. Denn es ist blöd, wenn man schon die Steaks in der Pfanne hat und dann erst feststellt, dass der Käse, den man zum Überbacken nehmen wollte, nicht mehr reicht.
Diese Antwort hatte ich bereits erwartet, als ich meine letzte Antwort schrieb. Programmiertechnisch gesehen, bedeutet das du teilst deine große Funktion in mehrere kleinere Funktionen auf, damit du den Überblick behälst. Ist das aber nicht das gleiche wie wenn du versuchst den Sichtbarkeitsbereich deiner lokalen Variablen zu verkleinern?
Ich habe mir außerdem überlegt, dass die Zutaten in einem Programm eigentlich eher den Funktionsparametern entsprechen und weniger lokalen Variablen. Z.B. eine Funktion salatZubereiten(Salat s, Essig e, Öl ö). Dann wäre natürlich der erste Schritt die Parameter auf Gültigkeit zu überprüfen, d.h. s.getGewicht() > 500g, e.getMenge() > 50ml, ö.getMenge() > 50ml. Ich würde als nächstes eine lokale Variable Spüle anlegen und den Salat in der Spüle waschen. Die Variable Salatschüssel würde ich erst dann anlegen, wenn ich sie brauche um den Salat reinzutun. Der Fall dass das Anlegen der Salatschüssel mit einer ThereIsNoSchüsselInYourKitchenException fehlschlägt wäre glaube ich ein ernster Programmierfehler. Schließlich sollte ich keine Funktion salatZubereiten schreiben wenn ich keine Salatschüssel hab.
Dann haben wir grundsätzlich unterschiedliche Arbeitsweisen. Ist ja nicht schlimm.
Wäre ja auch schlimm, wenn alle Menschen gleich arbeiten würden.
Das ist natürlich richtig - aber dann haben wir ja wieder genau das, was du vorhin als suboptimal dargestellt hast: Man gibt vor, C++ zu programmieren, und nutzt es wie C.
Hmm, es ist ja auch nicht verboten in C++ C-artig zu programmieren und es gibt sicher auch genug Einsatzbereiche wo es auch sinnvoll ist das zu tun (Mikrocontroller, performancekritische Abschnitte). C++ ist eben eine Multiparadigmensprache und jeder Sprachteil hat seine völlig legitime Daseinsberechtigung. Trotzdem sollte man gerade als Anfänger lieber cout, cin, ifstream, string, vector usw. nutzen anstatt mit fopen und malloc herumzuhantieren und dabei Gefahr zu laufen fclose und free zu vergessen.
C++ ist eben eine sehr komplexe Sprache und sie macht es leider einem Anfänger sehr schwer sich in diesem Dschungel zurechtzufinden.
Wobei ich es durchaus zu schätzen weiß, dass ein C++-Compiler in der Regel auch dann einige Syntax-Features von C++ unterstützt, wenn er per Compiler-Option im C-Modus betrieben wird (etwa einzeilige Kommentare oder anonyme unions).
Sind das nicht sowieso Eigenschaften, die es seit C99 auch in C gibt?
Ich empfehle einem Anfänger, der von PHP kommt, ...
Ein Anfänger, der von PHP kommt, ist sowieso schon verkorkst. ;-)
Ich bin überzeugt, dass man da noch was retten kann. Mein Weg hat nämlich auch über PHP geführt und ich denke ich habe den Absprung noch rechtzeitig geschafft ;-)
Diese beiden zusammen sind auch in der Tat mein liebstes Gespann. Dabei variiert der Assembler-Anteil je nach Projekt zwischen nahezu 0 und über 50%.
Dürft ich fragen wie groß deine Projekte dann im Normalfall sind? Ich denke große Projekte in Assembler umzusetzen kann man durchaus eine kleine Kunst nennen, da man dafür ja schon eine ganze Menge wissen muss.
Gruss,
OhneName