Objektorientierung anhand von Ruby und Go
Die meisten Skripts oder Programme starten als Hacks mit ein paar Variablen ins Leben. Erweist sich eine Applikation als nützlich, steigen die Ansprüche. Ein Feature hier, noch eins da, und die Codebasis wächst. Dem Beobachter fällt dann auf, dass sich Codeabschnitte wiederholen und sich besser als Funktionen zusammenfassen lassen. Auch die Zahl der Variablen steigt, und wenn Funktionsaufrufe fünf oder zehn Parameter enthalten, wächst das Verlangen, die Variablen in kleinen Gruppen als Strukturen zusammenzufassen, und sie platzsparend als Kombipakete herumzuschicken.
Der Wunsch, Funktionen fest an Datenstrukturen zu binden, ergibt sich auch ohne explizite Objektorientierung auf ganz natürliche Weise. Der in blankem C ohne OO-Unterstützung geschriebene Code des Webservers Apache zeigt etwa, dass dort viele Funktionen als erstes Element eine Datenstruktur erhalten, typischerweise als erweiterter Kontext. Sie besteht aus angesammelten Daten, auf die die Funktion nicht nur lesend zugreifen kann, sondern auch schreibend.
In Abbildung 1 bekommt die Funktion ap_get_useragent_host() als ersten Parameter eine Request-Struktur. In der hat der Server die bis dato analysierten Daten aus dem eingehenden Request abgelegt, und die Utility-Funktion fieselt daraus den User-Agent des Clients heraus. Ähnliches gilt vielleicht auch für eine Funktion, die einen Teil einer Webantwort zusammenbaut.
Daten zum Mitreisen gesucht
Eine objektorientierte Sprache würde die mitreisende Datenstruktur als Objekt bezeichnen, und Funktionen, die lesend oder schreibend darauf
