Ich finde nicht, dass das
OOP-Konzept für diese Aufgabe oversized ist. Eine Klasse muss ja nicht gleich die ganze Welt beschreiben, eine sinnvolle Klasse kann genausogut nur über ein oder zwei public-Methoden und einige Properties besitzen. Luckies Funktion beispielweise könnte man auch der Übersichtlichkeit wegen (Länge der Funktion nur Bildschirmhöhe) in mehrere private Unterprozeduren zerlegen, die dann in einer als public deklarierten Funktion, der eigentlichen Split-Funktion, aufruft. Die Parameter können über Felder geregelt werden.
Ich finde, man sollte von dem Gedanken wegkommen, Klassen lohnen sich nur bei umfangreichen Projekten.