Das mit der Wartbarkeit kann man nicht verallgemeinern. Das kommt ganz klar auf die vorherige Planung und den Programmierstil an. Plant man richtig, strukturiert alles sauber und weiß vielleicht schon im Voraus, wo man zukünftig was erweitern möchte, dann geht das prozedural fast genauso gut wie objektorientiert.
AAAAber: Ganz wahr ist das auch nicht. Denn Vererbung ist ein ganz wichtiger Aspekt, den man prozedural nur schwer abdecken kann. Ob man sowas braucht, kann man in der Planungsphase seiner Software evaluieren. Dazu müsste man aber erstmal wissen, was damit möglich ist. Dazu empfehle ich neutrale Tutorials, die man zu genüge im Internet findet.
Nopp hat geschrieben:Unterliegt die prozedurale Programmierung der OOP in irgendeiner Weise?
Es gibt Programmiersprachen, die können beides, z.B. Python. Dann gibt es welche, die können nur prozedural wie z.B. Purebasic. Und es gibt welche, die können nur objektorientiert, wie z.B. Java. Aber man kann auch mit Java prozedural Programmieren, indem man eine einzige Singleton-Klasse definiert und darin nur statische Methoden nutzt.
Nopp hat geschrieben:1. Wartbarkeit ist viel schlechter, da man bei Änderungen alles nachfolgende ebenso ändern muss
Das ist nicht wahr, da es wie oben schon erwähnt von der Planung abhängt. Natürlich kann man auch rein prozedural so programmieren, dass man nur an einer Stelle etwas ändern kann, ohne den Rest ebenfalls ändern zu müssen. Man muss eben Redundanz im Code vermeiden, sodass man bei einem Fehler auch nur an einer Stelle etwas korrigieren muss und nicht gleich an vielen.
Nopp hat geschrieben:2. OOP ist dichter an dem "wirklichem" Leben angesiedelt und daher einfacher zu verstehen
Auch das würde ich so nicht unterschreiben. Ob ich jetzt auto.start() schreibe oder start(auto) ist am Ende das gleiche. Aber ich muss zugeben, dass ich es sehr übersichtlich finde ein Klassendiagramm zu erstellen um die Beziehungen zwischen Attributen und Klassen herzustellen und dann erst die Entwicklung zu starten. Aber ich würde sagen das lohnt sich auch erst bei größeren Projekten.
Nopp hat geschrieben:Bzgl. Performance und der z.B. "benötigten Code-Zeilen" im Vergleich von beiden finde ich leider wenig.
Das kommt wohl immer noch ganz darauf an, was du machen möchtest. Solange du nicht an die Grenzen der in Purebasic eingebauten Befehle stößt, kommst du in Purebasic vermutlich mit weniger Codezeilen zum Ziel als mit VB.NET. Aber das kann ich nur schätzen. Sobald du API verwenden musst oder Befehle benötigst, die in Purebasic nicht existieren, dann kann sich der Code schnell mal etwas aufblähen, aber das ändert nichts an der Ausführungsgeschwindigkeit.
Apropos: Wenn du mit Purebasic ein Programm kompilierst, dann wird es zunächst in Assembler übersetzt und von da an dann direkt in Maschinencode. Je nach Plattform hast du dann ein Executable für Windows, Linux oder Mac. VB.NET kompiliert in einen Bytecode, vergleichbar mit Assembler, aber doch anders, denn er ist dann zunächst mal plattformunabhängig. Wenn man jetzt das .NET-Framework in Windows installiert hat, kann dieses Framework den Bytecode interpretieren, abspielen und gleichzeitig zur Laufzeit in echten Maschinencode kompilieren, der dann in voller Geschwindigkeit auf deinem Prozessor laufen kann. Das Schöne hieran ist, dass die Kompilierung zur Laufzeit sich an die Möglichkeiten deines Prozessors anpassen kann. Kann dein Prozessor bestimmte Instruktionen, die helfen würden das Programm schneller laufen zu lassen, dann werden diese genutzt. Kann er diese Instruktionen nicht, dann eben nicht. Purebasic hingegen nutzt während der Kompilierung nur einen begrenzten Teil der Instruktionen, die dein Prozessor zur Verfügung stellt, damit es überall laufen kann. Das muss am Ende aber nichts bedeuten. Es kommt immer noch darauf an, was du da überhaupt programmierst, ob du es effizient umsetzt und ob dir die paar Millisekunden Geschwindigkeitsunterschied überhaupt etwas ausmachen.
Du merkst vielleicht selbst, dass man hier keine klaren Grenzen setzen kann. Es ist alles situationsbedingt. Am Ende kommt es vielleicht doch auch nur darauf an wie viel und wie schnell du Hilfe bei Problemen bekommen kannst.
