Prinzipfrage: Wie hält man's mit OOP

[alzaimar]

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?