Die Anfuehrungszeichen lassen vermuten, dass Du es nicht praktisch findest. Warum?
Ich sehe hier eine Diskrepanz zwischen dem Wort "praktisch" und der Existenz von Protokollen. Smalltalk lebt von der Idee, daß man keine expliziten Interfaces (Protokolle) braucht, da man bedingt durch das dynamische Dispatching ohne auskommt. Es gibt keine expliziten Interfaces, weil man der Meinung ist, daß man per Rapid Prototyping und Unit Testing die Sache schneller und besser erledigen könnte. Anforderung an Objekte werden somit nur implizit durch die jeweiligen Methodenaufrufe definiert.
Der andere Standpunkt ist der, daß man Anforderungen an Objekte durch explizite Interfaces festlegt. Je nach Programmiersprache gibt es unterschiedliche Konstrukte, um dies zu gewährleisten. Protokolle in Objective-C sind so eine Methode. Genauer betrachtet sind Protokolle Mehrfachvererbung für Arme, da es ganz ähnliche Einschränkungen wie bei einer Mehrfachvererbung ohne Konfliktlösungsmittel gibt, aber man keine Polymorphie über diesen Weg umsetzen kann. Das heißt, man kann keine Methodenimplementationen vorgeben etc. pp., eben all das was Polymorphie in einer Vererbungshierarchie auszeichnet.
Mögliche Probleme bei der Mehrfachvererbung sind:
- Kollision von Methodenbezeichnern
- Kollision von Attributbezeichnern
- Kompliziertes statisches Dispatching notwendig
Wenn man dies mit Objective-C Protokollen vergleicht, dann fällt auf das Punkt 3 wegen des dynamisches Dispatchings eh kein Thema ist und Punkt zwei entfällt, da man keine Methoden erlaubt hat. Punkt 1 muß man manuell einhalten, es gibt keine Möglichkeit Konflikte aufzulösen wie in anderen Sprachen. Es bleibt festzuhalten Protokolle sind eine Technik dem Nutzer einer Klasse zu signalisieren, daß einen konkrete Klasse über einen Satz von Methoden verfügt. Dies bleibt aber hinter den Möglichkeiten von Mehrfachvererbung zurück.
Kommen wir zum Punkt wie man Programme mit beiden Techniken umsetzt.
Wenn man eine Methode schreibt, die als Argument ein Objekt übergeben bekommt, dann verlangt man nun von diesem Objekt, daß es bestimmte Kontrakte einhält, unter anderem bestimmte Interfaces zur Verfügung stellt, da der eigene Programmcode sich darauf verläßt. Man kann dies je nach Programmiersprache nun direkt bei der Parameterübergabe sicherstellen (Objekt ist von Typ X, Objekt erfüllt Protokoll X o.ä.) oder man macht dies implizit in dem man einfach im Programmcode erwartet, daß sich das Objekt wie ein Objekt des Typs X verhält.
Die große Frage ist nun wie man das am besten gewährleistet, so daß man dies auch in einem größeren Team noch gut umsetzen kann, oder nach Jahren selbst noch sieht, was man da eigentlich erwartet hat. Die explizite Formulierung hat den Vorteil, daß man direkt sieht was man vom Objekt erwartet. Wenn man verschiedene Methoden eines Objekts nacheinander aufruft ist dies nicht leicht zu erkennen.
Persönliche Wertung der Sache
Meiner Meinung nach hätte man in Objective-C Mehrfachvererbung einbauen sollen, der Mehraufwand in der Programmiersprache ist gering, weil man es mit einer dynamisch dispatchen Sprache zu tun hat ist es sogar relativ einfach umzusetzen. Protokolle sind eine weniger leistungsfähige Möglichkeit, die aber absolut notwendig sind, so daß man Eigenschaften von Objekten über einen Sprachmechanismus zusichern kann. Da ich schon Erfahrung mit Programmiersprachen mit Mehrfachvererbung habe, kann ich nur sagen, daß es unsinnig ist aus ziemlich fadenscheinigen Gründen darauf zu verzichten.
Desweiteren teile ich Deine Meinung nicht, daß die Möglichkeit ohne Protokoll oder Klassenzugehörigkeit eine Methode aufzurufen was tolles sei. Man verschleppt so Fehler und macht die Fehlersuche komplizierter und deutlich teurer. Aber dies ist der grundsätzliche Unterschied zwischen stark typisierten Programmiersprachen und schwach typisierten Programmsprachen.