Bei
OOP geht es ja nicht nur darum, eine Klasse zu basteln und den Parameter einer Prozedur als Instanznamen vorne ran zu bepseln (Foo(Bar) vs. Bar.Foo), sondern um die gesamte Sichtweise der
API.
Die
Win32-
API ist ja zu verwenden, aber dot.NET ist irgendwie übersichtlicher, nachhaltiger und klarer strukturiert. Und DAS war nunmal die Ausgangsfrage, und nicht, ob ich in einer
OOP-Umgebung auch mal Prozeduren schreiben soll, oder jeden Pups in eine Klasse packen muss (Dogmen sind der Tod der Kreativität). Das man in den einzelnen Modulen (Namespaces) durchaus prozedural rumfrickeln kann/sollte, steht doch gar nicht zur Debatte und ist
imho -mit Ausnahme in der Lehre- sowieso gängige Praxis und auch praktikabel.
Die Diskussion, was nun automatisch besser ist (Proc vs.
OOP) ist müßig, denn es kommt sowieso auf das Können an. Wenn ich aber von vorne herein etwas Neues auf die Beine stellen will, dann sollte ich doch -bitte schön- einen Ansatz wählen, der dem 21.Jahrhundert gerecht wird. Insofern finde ich die Bockigkeit von dem 'alten Hasen' eben etwas grenzdebil (außer er hat stichhaltige Argumente).
Klar, bei plattformübergreifenden Lösungen muss man erst mal den kleinsten gemeinsamen Nenner finden und bei einer Plattform, die
OOP nur bedingt unterstützt, scheidet
OOP nun mal aus. Aber das ist doch banal. Wenn ich mir die Frage schon stelle (
OOP oder nicht
OOP?), habe ich doch schon abgeklopft, das
OOP im Prinzip ginge, oder nicht?