In letzter Zeit gibt es einen recht großen Hype um das Thema dynamisch typisierte Sprachen. Prototypisch ist dabei das Thema Ruby und insbesondere Ruby on Rails. Ein wesentlicher Teil der Argumentation ist dabei, dass ein wesentlicher Vorteil von Ruby die dynamische Typisierung ist. Dadurch sollen sich zum Beispiel die Verwendung von Aspekten oder Mocks deutlich vereinfachen. Einen Mock zu bauen, ist nicht mehr zu kompliziert, weil man keinen Typ festlegen muss und nur die Methoden implementieren muss, die tatsächlich aufgerufen werden. Aspekte versuchen trotz statische Typisierung dafür zu sorgen, dass man in die Methodenaufrufe noch eingreifen kann. Hier verwendet Ruby ein Renaming der Methoden, mit denen man die Klassen ergänzen kann.
Letztendlich ist nun die Frage, ob eigentlich die dynamische Typisierung wirklich das Thema ist. Eigentlich geht es eher darum, dass Methodenaufrufe durch Messages ersetzt werden. Dieses ist ein kleiner Unterschied und vor allem ein Unterschied in der Art und Weise, wie man über die Kommunikation zwischen Objekten nachdenkt. Prototypisch ist das "Message Not Understood" von Smalltalk. Damit kann man an einer Klasse eine Methode deklarieren, die aufgerufen wird, wenn eine nicht bekannte Methode aufgerufen wird. Mit dem Methoden-Begriff darüber nachzudenken, macht wenig Sinn. Mit dem Messages-Begriff geht es besser: Diese Message wird ausgelöst, falls die Message nicht anderweitig ausgeführt werden kann. Übrigens wird es dadurch ein leichtes, Delegation zu implementieren oder auch Dinge, für die man bei Java CGLIB oder Dynamic Proxies braucht.
An dieser Stelle kommt man auch recht schnell auf das Command Pattern: Letztendlich ist es ein Verfahren, mit dem man auch sowas wie eine Umschreibung eines Methode als Message implementiert. Dies hat die bekannten Vorteil, dass man zum Beispiel in einer GUI den Elementen jeweils Commands zuordnen kann, die definieren, was ausgeführt werden soll, man kann Undo und Redo recht leicht implementieren usw. Von da aus ist es dann auch kein weiter Schritt zu Message Oriented Middleware: Dort werden auch Messages ausgetauscht statt Remote Procedure Calls, was in Bezug auf die Zuverlässigkeit positiv ist, weil man die Messages speichern kann und dadurch so lange Vorhalten kann, bis sie bearbeitet werden. Ebenfalls spielen Latenz-Zeiten keine so große Rolle.
In letzter Instanz bedeutet dies, dass man über Objektorientierung und den Methoden-Begriff nochmal nachdenken muss. Welche konkreten Konsequenzen sich daraus ableiten, ist eben die Frage, die man dann beantworten muss... ¶ 09:16
