Immer diese blöden Autos

[dedlfix]

Tach!

warum wird in fast jedem Buch, Tutorial usw. wo das Thema OOP behandelt wird über Autos gesprochen. Ein Auto hat Türen, kann nach vorne fahren, Motor einschalten, ausschalten...
Ist das das "Hello World" für OOP?

Es ist zumindest ein Einstieg, um Laien an das Thema heranzuführen und um ihnen einen Vergleich mit einem bekannten Thema zu geben.

Ist noch keiner auf die Idee gekommen, ein sinnvolleres Beispiel zu nehmen?

Dummerweise sind Real-World-Beispiele wenig geeignet, konkrete Probleme beim Programmieren zu besprechen. Man sollte sich also schnell wieder von solchen Vergleichen lösen. Man programmiert kein ganzes Auto oder ein Restaurant, man hat vielmehr irgendwelche kleinen Details zu beachten und Lösungen für programmiertechnische Aufgabenstellungen zu finden. Wenn man anhand dessen die OOP erklären will, muss man erst einmal die Tätigkeiten beim Programmieren an sich erklären.

Nun kommt es auch noch drauf an, was derjenige OOP-Lehrling bereits kennt. Hat er schon erste oder weitergehende Erfahrungen im prozeduralen Programmieren gesammelt? Datenbankenabfragen vielleicht? Dann könnte man die OOP anhand von DBMS-Abstraktionen erklären. Es gibt ein paar Grundfunktionalitäten und es gibt DBMS-spezifische Dinge. Das sollte für das Erklären von Vererbung und abstrakten Methoden reichen. Um Szenarien für Interfaces kann man das sicher auch ausbauen.

Wenn er nun aber ohne weitere Kenntnisse gleich in das Programmieren mit einer OOP-Sprache einsteigt, dann hat man wenig, auf dem man aufbauen könnte. Die Frage ist dann allerdings, ob man gleich das volle OOP-Programm fährt oder erstmal nur notwendigerweise eine Klasse als Container nimmt und die Programmier-Basics mit einer Geradeaus-Programmierung in der main-Methode erklärt. So fangen zumindest einige Window-Programmierbücher an: mit einer Konsolenanwendung. OOP kommt später. Von Geradeaus-Programmen auf eventgesteuerte GUI-Anwendungen zu kommen ist auch nochmal eine ziemliche Umstellung. Denn dann hat man nicht mehr die generelle Kontrolle über das Programm, das gelegentlich zum Ausführen einer Systemfunktion abtaucht, sondern das läuft quasi die meiste Zeit unter Wasser ab und taucht nur mal für ein paar Eventhandler auf. Und dabei bleibt man ja nicht stehen. Eventhandler sind schlecht test- und austauschbar und zu sehr an die GUI-Objekte gekoppelt. MVVM (Model-View-Viewmodel) steht dann auf dem Plan. Das sind nun keine Dinge mehr, denen ein Autofahrer begegnet. Das sind Probleme die beim Programmieren entstehen, sobald die Projekte größer werden und man dafür überschau- und wartbare Lösungen braucht.

dedlfix.