Das hier wäre ein hübsches Problem, um mit eigenen Klassen modelliert zu werden: Reflektion eines Lichtstrahls im Quadrat visuell darstellen

Jeder Punkt, an dem der gebrochene/gespiegelte Lichtstrahl seine Richtung wechselt, muss ja berechnet und gemerkt werden. Später kannste dich noch dran verkünsteln, das auch grafisch darzustellen.

@Brötchen29 wirds dir danken.

Sinnvolle Aufgabenstellungen mit Klassen zu finden (die nicht trivial sind) ist garnicht mal so einfach. Typisch sind Vektor- oder Bruch-Klassen, aber die sind recht Mathematik-lastig und man lernt eher Sprachfeatures (wie Operator-Überladung) als OOP-Prinzipien.
Häufig fallen Klassen auch in ein fix vorgegebenes Schema. Forms sind beispielsweise auch Klassen. Aber da muss man sich keine großen Gedanken machen, denn der Designer bastelt den Code für die Oberfläche selbst und von der Architektur her gibt's da nicht viel.
Nicht selten will man auch einfach nur Funktionen, die was miteinander zu tun haben, zusammenorganisieren.

Alte Schuhe wären eine ArrayList oder eine LinkedList (ganz einfach oder optimiert; einfach oder doppelt verkettet). Ganz nett finde ich auch, bei den Listen das Iterator-Pattern dazuzuhängen.

also ich finde Zeichen-Klassen wirklich nett, grade in WinForms.
Das ist klassischer Anwendungsfall von Klassen, denn eine Klasse soll man nur anlegen, wenn man auch wirklich mehrere Objekte davon braucht - und das braucht man, wenn man 2 Männeken darstellen will.
Und da gehts auch ganz schnell zur Vererbung hin, denn wenn du Männeken und Bälle hast, so sind das unterschiedliche Klassen, die aber auch ganz viel gemeinsam haben (sollen sich ja alle zeichnen können).

Oder Brötchens Optik-Problem: Die Lichtstrahlen sind zu zeichnen, die Brech/Spiegel-Punkte - inklusive Beschriftung, und der Würfel selbst natürlich.
Aber das greift schon vor, denn zunächst mal müssen Würfel, Strahlen und Punkte ja erst noch berechnet werden - das wären schoma 2 - 3 Klassen (Würfel kann man auch einfach erstma ein Rectangle nehmen).

Eine Basis-Klasse mit dem Grafik-Kram zu unterlegen wäre ein zweiter Schritt.
Wahrscheinlich wärs sogar erst der dritte schritt, und der 2. Schritt wäre, dass jede Klasse selbst ihren Zeichen-Kram an Bord hat, und das Auslagern der Gemeinsamkeiten kommt erst danach, um den Code zu vereinfachen.

Modelliere z. B. eine Stadt, ein Land, die Welt...

Oder mache Gedanken ueber ein Simulationsspiel.

Das wird aber glaub schnell zu groß, und dann muss man wieder mit Datenbänkerei ankommen - typDataset oder EF - sich also die Klassen generieren lassen.

@vb_fan
Bei so Welt-Modellierungs-Sachen bin ich immer etwas skeptisch. Denn häufig lassen sich Objekte aus dem echten Leben nicht ohne weiteres modellieren. Ich nehme da immer gerne einen Artikel von Eric Lippert als Beispiel: ericlippert.com/2015/04/27/wizards-and-warriors-part-one/
Magier und Krieger sind Spieler
Zauberstäbe und Schwerter sind Waffen.
Ein Spieler hat eine Waffe.
Wie kann man jetzt festlegen, dass ein Magier keine Schwerter und ein Krieger keine Zauberstäbe verwenden darf?

Und häufig kommt man drauf, dass die offensichtlichste Lösung nicht unbedingt die beste ist. Wenn man beispielsweise einen Raum modelliert, in dem Spieler herumlaufen können, dann wäre die offensichtlichste Lösung, in der Raum-Klasse eine List von Spielern zu hinterlegen. Aber häufig muss man von einem Spieler wissen, in welchem Raum er sich befindet. Dazu muss man in der Spieler-Klasse einen Verweis auf den Raum haben, in dem er sich befindet.
Also ganz besonders solche "X befindet sich in Y" Relationen kann man häufig nicht 1 zu 1 modellieren.


Edit:
Wie ErfinderDesRades vorgeschlagen hat, eine Zeichen-Klasse. Das könntest Du versuchen, mit dem Ziel, eine Art Schaltplan-Designer zu erstellen. Einerseits müssen Objekte auf gleiche Art manipuliert werden können (verschieben mit Drag&Drop, rotieren, etc.), andererseits können unterschiedliche Objekte unterschiedliche "Spezialaktionen" haben (z.B. einen Schalter umschalten oder die Einstellung eines Potentiometers verändern). Es müssen auch Leitungen an Kontakte angeschlossen werden können. Und dann braucht man noch eine Möglichkeit, festzulegen, in welcher Reihenfolge Dinge gezeichnet werden sollen (z.B. dass Leitungen immer über Objekte drüber gehen).

also du willst gleich mit OwnerDrawing einsteigen.

dann guggemol activevb.de/cgi-bin/tippupload…beweglicher_Figur_darstel
Das ist eine Figur-Klasse, die sich selber zeichnen kann, und das ist wichtig, dass du kapierst, wie die tickt, nämlich die greift auf Matrix und GraphicsPath zurück - wenn du anfängst, für 3-Ecke, 4-Ecke und Kram eigene Klassen zu entwerfen, bist du schon auffm Holzweg, das ist alles bereits über GraphicsPath abgedeckt.

Den Color-Generator aussm Sample kannste erstmal weglassen - das ist ein Gimmick, und Hilfsmittel zur Visualisierung des Clippings.
Am besten löschen, und alle Verweise entfernen, und den Code wieder hinbiegen - dann sollte er wesentlich einfacher zu schnallen sein (aber immer noch anspruchsvoll genug).

naja, beim Brötchen-Problem wären die Brechpunkte ja erst überhaupt mal auszurechnen.

Im Kern zeigt der von ErfinderDesRades verlinkte Code zwei wichtige Dinge:
1. Gezeichent wird im Paint-EventHandler. Also nicht Me.CreateGraphics verwenden, sondern OnPaint überschreiben (oder das Paint-Event abonnieren) und dort zeichnen.
2. Beim Ändern von Objekten sollte man nicht immer die ganze Zeichenfläche invalidieren (z.B. mit Me.Invalidate()). Stattdessen sollte man vor dem Ändern nur die geänderten Bereiche invalidieren (für jedes zu ändernde Objekt Me.Invalidate(GeänderterBereich) aufrufen), dann die Änderungen machen, und dann nochmal die geänderten Bereiche invalidieren.