Um OOP zu verstehen ist es imho hilfreich wenn man erst vom reinen Programmieren Abstand nimmt und die Sache etwas abstrakter betrachtet. Also vergiß so technische Details wie Klassen, Methoden und Objekte für einen Moment und denk darüber nach worum es geht.
Da ist auf der einen Seite ein Computer, den wir dazu benutzen wollen Aufgaben für uns zu erledigen. das Problem dabei ist, daß dieser Computer trotz all seiner Rechenleistung dumm ist. Er tut genau das was wir sagen, nciht mehr und nicht weniger. Mit einem Programm beschreiben wir was der Compute für uns machen soll, aber dabei haben wir ein Problem, wir sind Menschen
Wir machen Fehler, vergessen Kleinigkeiten oder drücken uns ungenau aus. Solange wir mit Menschen reden, ist das egal weil Menschen solche Fehler automatisch korrigieren und Kleinigkeiten, die wir vergessen hinzufügen. (Eine beliebte Quelle für Mißverständnisse btw).
Reden wir aber mit Computern wird das zum Problem, denn dieser hat null Toleranz zu Ausdrucksfehlern. Wenn wir uns falsch ausdrücken, fürht er es auch ebenso falsch aus.
Die ersten Computersprachen waren sehr technische Sprachen, geschrieben von Freaks die sich damit gut auskannten und die wußten was sie taten. Sprachen wie C lassen dem Programmierer nahezu vollkommene Freiheit in dem, was man damit machen kann. Das geht auch gut, solange der Programmierer sehr genau weis, was technisch in einem Computer abläuft.
Doch sind diese Zeiten längst vorbei. Wer weis denn schon noch was eine ALU ist, oder ein Register, wie der Speicherzugriff geht usw. Die Fähigkeiten daruf direkt zugreifen zu können, die einem C noch geboten hat (und die man in Zeiten sehr geringern Rechnerperformance auch noch brauchte) sind lange vorbei, ebenso wie die Zeiten von Programmierern, die sich mit sowas noch auskennen mußten (und wollten).
Ich nenne C auch deswegen eine technische Sprache, weil sie sich stark an der "Computersprache" orientiert. Ein Mensch aber tut sich damit sehr schwer, wie ein Computer zu denken.
Objektorientierte Sprachen dagegen sind eher menschliche Sprachen. Sie beschreiben ein Programm auf eine eher natürliche, menschlichere Weise. Betrachte z.B. eine Firma. Da gibt es Abteilungen, jede für sich auf eine Aufgabe spezialisiert. Untereinander kommunizieren diese Gruppen über Schnittstellen (aka Meetings
). Viele Abteilungen halten dabei auch ihre Aufgaben mehr oder weniger geheim. So kommt z.B. keiner ausser den IT Jungs in den Serverraum und die Buchhaltung hält ihre Akten verschlossen. Solche Strukturen benutzen wir Menschen seit eh und jeh und allen Bereichen unseres Lebens.
Ersetze jetzt Abteilungen mit "Klassen", Mitarbeiten mit "Objekten", Arbeitsabläufe mit Methoden und schon bist Du mitten im OOP-Programmieren. Beim OOP-design eines Programmes geht es darum, die Abläufe des Programms auf eine dem Menschen eher verständliche Weise darzustellen.
Darüber hinaus gibt es weit mehr Aspekte wie Kapselung von Funktionalität, leichtere Wartung/Fehlersuche, Erweiterbarkeit etc die dem OOP Vorteile gegenüber prozeduralen Vorgehensweisen bieten. In erster Linie aber ist es lediglich eine andere Sichtweise wie man seinen Code aufbaut und erst wenn man das verstanden hat, beginnt man auch tatsächlich objektorientiert zu programmieren.
