Noch mehr Methoden

Gestern habe ich über Attribute und Methoden von Objekten gesprochen. Zwei Punkte möchte ich noch ergänzen.

Hilfsmethoden

Dieser Punkt ist leicht neben dem gestrigen Thema, da die Methoden überhaupt nicht von dem Objekt abhängen. Das Objekt wird der Methode als unsichtbarer (Ausnahme: Python) erster Parameter übergeben. Einige Methoden benutzen diesen Parameter aber nicht. Daher können sie auch, bei entsprechender Deklaration, so daß der Compiler einverstanden ist, ohne das Objekt direkt als Methode der Klasse verwendet werden. In diesem Fall dient die Klasse nur als Schublade für die Methode. Eigentlich handelt es sich bei einer Klasse, die ausschließlich solche Methoden enthält um ein Modul. Derartige Methoden werden häufig als Utility- oder Hilfsmethoden bezeichnet.

Wenn die Methoden Parameter haben, könnten sie auch als Methode eines der Objekte übergeben werden, die als Parameter dienen. Die ist in Ruby immer möglich. In anderen Programmiersprachen kann es aus zwei Gründen scheitern. Erstens ist nicht immer jeder Parameter ein Objekt. Das ist z.B. das Thema einer Mathematik-Bibliothek, wie sie sich u.a. bei Java findet. Zweitens kann es sich um ein Bibliotheksobjekt handeln, das nicht erweitert werden kann, da es final oder sealed ist. C# behilft sich hier mit extension methods, die bei Verwendung ähnlich aussehen als ob die Klasse erweitert worden wäre. In Wirklichkeit wird aber eine separate Klasse mit Hilfsmethoden verwendet. Dies sieht zwar hübsch aus, hat aber seine Tücken. Insbesondere ist das Verhalten bei Vererbung nur zu verstehen, wenn man weiß, was dahinter steht.

Zugehörigkeit von Methoden

Der aufmerksame Leser hat bei den vorherigen Ausführungen vielleicht schon gemerkt, daß es oft ein wenig willkürlich ist, welcher Parameter einer Methode herausgehoben wird, indem man die Methode der Klasse seines Typs zuordnet. Ein Beispiel, über das ich immer wieder stolpere ist die join-Methode, die sich in verschiedenen Bibliotheken findet. Sie dient dazu aus einem Array einen String zu machen, indem sie die Stringrepresentation der Arrayelement mit einem Separatorstring verknüpft. Es gibt also die join-Methode, ein Array und einen Separatorstring. Für mich erschiene es natürlich, diese Methode dem Array zuzuordnen und den Separatorstring als Parameter zu übergeben. Der Autoren etlicher Bibliotheken sehen das aber umgekehrt und machen die join-Mehtode zu einer Methode der String-Klasse. Das ist eine völlig legitime Sichtweise.

Solche Probleme hat man natürlich nicht, wenn die Methoden unabhängig von den Klassen definiert werden, wie es in CLOS der Fall ist.