Der "Informatiker" ist aber nicht wirklich ein Programmierer, also nicht zwangsläufig. Der studierte Herr Informatiker sollte natürlich Ahnung von der Programmierung haben, damit er weiß wie er welches Problem in welcher Sprache wie anzugehen hat. Bzw. sollte wissen welche Probleme man mit welchen Patterns am Besten erschlägt und wie man sie umsetzt. Aber grundsätzlich muss der Herr Informatiker keine Zeile Code schreiben können. An der Uni laufen nicht wenige Informatiker mit 1er Schnitt rum, die Stunden brauchen, um ein kleines Java-Programm zu lesen, aber dafür dir im Detail erklären können wie der Code arbeiten sollte damit er möglichst effizient mit den Ressourcen umgeht oder wie man welche Art von Daten am Besten sortieren sollte.
Einfach ausgedrückt: Der studierte Herr Informatiker entwirft dein Programm in mehr oder weniger theoretischer Form. D.h. (UML-) Diagramme, Texte und sonstige Bilder. Das können insgesamt gut und gerne 100-2000 Seiten sein. Diese Informationssammlung ist so vollständig und detailreich, dass jeder Idiot (hier nun der "Programmierer") sie in ein funktionierendes Programm umsetzen kann. Dabei können diese theoretischen Abhandlungen so generisch sein, dass das Programm wirklich Idiotensicher in x beliebigen Sprachen umgesetzt werden kann, ohne auch nur eine Sekunde nachdenken zu müssen.
Ich persönlich bin aber eher für den Zwischenweg: Wenn ich ein Programm theoretisch ausarbeite und dabei weiß um welche Sprache es sich handeln wird (und natürlich mich in der Sprache und den Frameworks auskenne), kann ich 1. viel präziser formulieren, 2. Optimierungen vornehmen, 3. bei Unklarheiten und Problemen helfen.
Die anderen sind dann eher die reinen Theoretiker, die Algorithmen entwerfen, bei denen dann jeder selbst schauen muss wie einfach oder schwer das in der jeweiligen Sprache zu meistern ist.
Also z.B. für einen Sortieralgorithmus kann auf dem Papier stehen: Jetzt müssen die Elemente A und B getauscht werden (wobei nicht definiert ist, ob diese "Elemente" als Pointer oder Integer oder sonst wie realisiert sind). Oder man macht es konkret für den Anwendungsfall und schreibt: Jetzt müssen die Integer-Werte von A und B die Speicherzellen tauschen.
----
Bzgl. OOP und MVC. Die beiden Konzepte haben erstmal nichts(!) miteinander zu tun. Dieser OOP "Hype" geht schon seit 20 Jahren so
Und diese Art der Programmierung hat im Normalfall riesige Vorteile für die Strukturierung der Programme. Also prinzipiell macht es keinen großen Unterschied, ob du in C++ eine Klasse schreibst, oder in C ein Struct, das mit ein paar Pointern auf Funktionen ausgestattet ist ... außer dass die C Version umständlicher in der Handhabung ist.
In Webangelegenheiten (also PHP, Rails, etc.) kann ich dir sogar zum Teil zustimmen. Da würde man vermutlich auch ohne OOP auskommen. Aber sobald das Programm größer wird und es "ähnliche" Datenstrukturen gibt, da will man nicht mehr ohne Vererbung arbeiten. Und sich auch nicht mehr kümmern, ob die aktuelle Funktion zum Datentyp passt oder nicht.
Und MVC (wie auch MVP) sind äußerst praktische Konventionen. Stell dir vor, du hättest eine riesige HTML Seite, an jedem Button würde im "onclick"-Attribut direkt der JavaScript-Code eingebettet sein, den er ausführt und zusätzlich natürlich auch im Style-Attribut der CSS-Code. Also je nach Button könnten da schon gut und gern 10-30 Zeilen Code bei entstehen. Das will niemand (und ist der häßliche Extremfall
).
Der Grund warum es heute so beliebt ist:
1. Du kannst einen Webdesigner hinsetzen, der das Layout übernimmt und CSS schreibt und daneben einen Webprogrammierer, der den JavaScript Code schreibt und beide arbeiten an verschiedenen Dateien und doch an derselben Seite ohne sich in die Quere zu kommen oder durch den Code des anderen behindert zu werden.
2. Angenommen dein MVC Code ist fertig und er stellt eine GUI für einen Desktop PC dar. Und nun willst du noch eine GUI für ein Smartphone bauen. Dank MVC veränderst du ausschließlich den View-Code. Der Controller stellt nämlich schon die passenden Daten bereit und den interessiert es nicht welche du davon nutzt und wie häufig und wo.
3. Dank MVC kann ich mich in fremde Projekte wesentlich schneller einlesen (da ich mich meist ausschließlich für Model und Controller interessiere). Ich schau mir das Model an und stelle fest: Ah, da steht ein Int statt eines Boolean, kein wunder, dass das seltsamen Output produziert. Oder ich schau mir die Methoden im Controller an, ohne dabei von irgendwelchem Markup belästigt zu werden
Natürlich schreibt man sowohl durch OOP als auch durch MVC im Endeffekt meist 5% mehr Code, dafür ist er aber überaus sauber strukturiert (natürlich ein gewisses Maß an Kompetenz vorausgesetzt) und man findet sich unabhängig von der Sprache ziemlich einfach und schnell zurecht.
Den will doch niemand pflegen ...
