Als das Schlagwort “OOP” aufkam, wollte sich natürlich jeder damit schmücken. Ein Teilnehmer in einer Newsgroup erzählte damals den Joke, würde er seine Katze in einem Forum für Tiervermittlungen anbieten, würde er nicht ihre Liebe, ihre Reinlichkeit, die ausstrahlende Ruhe und ihre Zielstrebigkeit bezüglich Mäusen herausstellen, sondern er würde sie “objektorientiert” nennen.
In diesem Artikel
Negativbeispiel
Seinerzeit hatte ich mit einem Kollegen an einem Access-Projekt gearbeitet. Wir haben unterschiedliche Aufgabenbereiche innerhalb der Applikation bearbeitet, jeder natürlich auf seine spezifische Weise. Dabei ist mir zum ersten mal aufgefallen, wie unterschiedlich dies sein kann. Während ich eher von der prozeduralen Entwicklung geprägt bin, aber Klassen dort einsetze, wo es mir sinnvoll erscheint, hat der Kollege in seinem Projektteil konsequent alles objektorientiert umgesetzt.
Das klingt jetzt erstmal nicht so spektakulär. Schließlich ist es ja nur konsequent, wenn man ein sinnvolles Prinzip auch wirklich benutzt. Aber mit “konsequent alles” meine ich wirklich konsequent alles! Jede auch noch so kleine Funktion wurde bei ihm zu einem Klassenmodul. Deren Argumente wurden Properties, jeweils natürlich mit ausprogrammiertem Getter und Setter. Der entsprechende Wert wurde dann zunächst in einer privaten Variablen gespeichert. Zusätzlich gab es eine Ausführungs-Methode, und erst nach deren Aufruf konnte das Ergebnis aus einem weiteren Get-Property ausgelesen werden.
Aus einem einfachen Aufruf wie
ergebnis = MeineFunktion(eingabe1, eingabe2)
wurde dann
Set hilfe = New MeineKlasse hilfe.wert1 = eingabe1 hilfe.wert2 = eingabe2 hilfe.berechne ergebnis = hilfe.ergebnis Set hilfe = Nothing
Entschuldigt bitte, aber das ist meiner Ansicht nach absoluter Overkill! Dabei wird Objektorientierung eher zum Applikationskiller als dass sie Vorteile bringt.
Wann Klasse, wann Funktion?
Da stellt man sich natürlich die Frage, wann OOP denn überhaupt Vorteile bringt. Wann sollte ich eine Klasse programmieren, und wann lieber auf eine einfache Funktion setzen?
Mein pragmatischer Vorschlag dazu: Wenn eine Funktion ausreicht, um die Aufgabe zu lösen, dann verwende ich sie und programmiere nicht eine unnötig aufwändigere Lösung.
Anders sieht es natürlich aus, wenn ich mehr als ein Ergebnis erwarte. Dann ist eine Funktion (zumindest unter VBA) nicht mehr geeignet, da die Funktion nur einen Ergebniswert zurückgeben kann. Man könnte zwar auch ein Ergebnis-Array erzeugen und zurückgeben, aber dies müsste dann wieder zerpflückt werden, was den Aufruf wieder etwas umfangreicher machen würde.
Ebenfalls könnte man die Situation überdenken, wenn einige der Parameter sich verändern, andere jedoch nicht, und jeweils das Ergebnis neu berechnet werden soll.
In diesen Fällen könnte eine Klasse die Sache übersichtlicher machen.
Auch das Design Pattern Singleton benötigt eine Klasse, selbst wenn diese nur sehr einfach ausgestaltet sein sollte. Der Vorteil bei diesem Pattern ist, dass die Erzeugung der Instanz quasi verdeckt geschieht, und auf das Zerstören danach zunächst verzichtet wird. Damit verbleibt bei Benutzung nur noch das Setzen neuer Werte und/oder das Abholen des Ergebnisses, was die Sache recht übersichtlich macht.
Doch nur Ansichtssache?
Kann man nun eine Regel festlegen, wann eine Sub/Function ausreicht und wann es eine Klasse sein sollte? Ja, vielleicht. Ich will keineswegs behaupten, dass das allgemeingültig sei, aber meiner Ansicht nach sollte immer dann eine Sub oder Function verwendet werden, wenn deren Funktionalität für die Aufgabenstellung ausreicht. Wenn es darüber hinaus geht oder unnötig umständlich wird, sollte über eine Klasse nachgedacht werden.
Letztlich enthält Programmierung ja doch auch etwas künstlerische Freiheit, und es gibt vermutlich nie nur eine einzige Möglichkeit, eine Aufgabe umzusetzen.
Neueste Kommentare