Hallo Matthias,

auch mal wieder was von mir. Auch wenn ich meistens nur lesend hier dabei bin. Aber Deinen Ansatz finde ich interessant.

Dir geht es ja darum, Deinen _Schülern_ anhand Schere-Stein-Papier die OOP näherzubringen. Finde ich super. Ein guter Ansatz. Ganz wirst Du um das doofe Auto-Beispiel aber nicht rumkommen, so schlecht ist das nämlich meiner Meinung nach gar nicht (auch wenn's mich nervt; aber für mich das Ganze auch nicht mehr neu).

Was mir aber beim Lesen der anderen Antworten aufgefallen ist: Da sind wirklich gute, ausgereifte Antworten dabei. Meiner Meinung nach gehen die aber an einem _Lehrbeispiel_ etwas vorbei. Es geht doch gar nicht in erster Linie um die Implementierung, sondern um das Verständnis, was OOP bedeutet. Dabei kann und sollte man auch Dinge machen, die man in der Praxis so nicht machen würde, wenn es denn dem Verständnis dient. Dass auch OOP nicht das Allheilmittel ist und man bei Änderungen häufig auch trotzdem mehrere Dateien anpacken muss - wie hier schon erwähnt wurde - ist doch gar nicht schlimm.

So zurück zu den Autos :-) [Noch eine kurze Anmerkung: Folgendes ist natürlich noch keine fertige Lösung und soll nur in ein Gedankenanstoß sein.]

Das Autobeispiel ist gut, weil jeder weiß, wie ein Auto aussieht. Im Sinne der OOP veranschaulicht es sehr schön, dass ein Objekt Eigenschaften und Methoden besitzt. Aber natürlich haben die Meisten hier, ebenso wie ich, keine Lust mehr auf _dieses_ Beispiel. Deswegen finde ich auch Deinen Ansatz spannend (könnten sich einige Lehrer mal ne Scheibe von abschneiden).

Dann übertragen wir das "Auto-Beispiel" eben auf "Schnick-Schack-Schnuck".

Als erstes müssen wir überhaupt verstehen, was das Spielprinizip hinter "Schere-Stein-Papier" ist:

• Stein schlägt Schere
• Schere schlägt Papier
• Papier schlägt Stein

Aber warum? Meiner Meinung nach wegen ihrer Eigenschaften:

• Ein Stein ist "hart", er "zertrümmert" die Schere
• Eine Schere ist "spitz", sie "schneidet" das Papier
• Papier ist "flexibel", es "umwickelt" den Stein

Wo ich gerade sehe, was ich bis jetzt geschrieben hab, sind wir der OOP ja schon näher, als ich vorher gedacht hätte...

Also:

• Stein, Schere und Papier sind Objekte

• Ein Stein hat die Eigenschaft "hart"

• Eine Schere hat die Eigenschaft "spitz" bzw. "scharf"

• Papier hat die Eigenschaft "flexibel"

Jedes besitzt eine "Angriffsvariante":
Stein => "zertrümmern"
Schere => "schneiden"
Papier => "einwickeln"

Das wäre dann wohl eine Methode (Name z.B. "Angriff", die allen Objekten gemein ist und die in eine abstrakte Oberklasse ausgelagert werden kann).

Brauchen wir noch etwas, was die Korrelation herstellt:

• Ein Objekt kann etwas "spitzes" "zertrümmern"
• Ein Objekt kann etwas "flexibles" "schneiden"
• Ein Objekt kann etwas "hartes" "einwickeln"

Das wäre dann eine weitere, sozusagen eine "Konfigurations"-Klasse.

Fehlt noch eine Klasse, die das auswertet. Sie könnte zwei "normale" Objekte (Schere, Stein, Papier) sowie ein "Konfigurations"-Objekt erhalten und dann die Prüfung durchführen.

Ich "muss" jetzt leider Fußball gucken. Ich melde mich später nochmal. Nur noch zwei Dinge:
1. Es ist nur ein Gedankenanstoß
2. Sollte bspw. die "Prüfklasse" zu kompliziert werden (was ich aber nicht denke) spricht meiner Meinung nach auch nichts dagegen, wenn Du sie implementierst und den Schülern zu Verfügung stellst. Denn darum geht es ja gar nicht. An der Uni wird sowas übrigens auch ständig gemacht, weil die Lehrzeit sonst gar nicht ausreichen würde.

Gruß und bis später,
Dennis