Meinst du ein bestimmtes "delegate" oder allgemein wie z.Bsp.: UITextFieldDelegate ?

Wenn man das mal ein wenig de-abstrahiert, dann ist das eigentlich ganz einfach.

Es gibt viele Objekte, die brauchen zusätzliche Informationen um zu funktionieren. Nehmen wir als einfachstes Beispiel mal ein TableView.

Dieses muss sich irgendwoher seine Daten besorgen. Dafür hat es sein Delegate (naja eigentlich seine Datasource, aber das ist auch nichts anderes). Früher hätten wir so etwas Callback genannt. Denn was macht das Tableview ? Es fragt einfach ein anderes Objekt, was für Daten es eigentlich darstellen soll. Sprich, es ruft mehrere Methoden auf, die sein Delegate implementieren muss. z.B. die Methode
numberOfRowsInSection(). Die Tabelview fragt also ihren Delegate "Ey Delegate, wie viele Zeilen gibts denn eigentlich in dieser Sektion?" und sein Delegate muss darauf antworten. Denn wenn das Tableview keine Antwort bekommt, dann kann es nicht funktionieren.

Gruß

Claus

Ein wichtiges Element von Delegates ist, dass sich ein und dieselbe View-Klasse unterschiedlich verhalten kann, abhängig von dem, was das Delegate der View-Klasse sagt.

Ein Beispiel unter iOS ist die UITableView-Klasse. Man verwendet die Klasse so, wie sie ist, in unterschiedlichster Art und Weise, einfach dadurch, dass man verschiedene Delegate-Klassen implementiert, die auf die "Fragen" des UIViews unterschiedlich "Antworten" (oder nicht antworten).

Apple beschreibt es gut:
"Delegation provides a way for your custom object to communicate application-specific behavior to the off-the-shelf object."

No.

Delegates sind gar keine Magie. Nichtmal was besonderes.

Irgendeine Klasse hat halt einfach eine Property "id delegate". Und irgendwo im Code wird dann blindlings [delegate doSomething] aufgerufen. Wenn irgendwer (eine andere Klasse) dies Property gesetzt hat (auf sich selbst), dann bekommt eben dieser irgendwer die "doSomething" Nachricht. Wenn nicht, bleibt delegate nil und [nil doSomething] hat halt kein Effekt.

Und: Da gibt's keinen Master und keinen Slave. Das delegierende Objekt und das Delegate arbeiten zusammen. Das delegierende Objekt ist anpass- und erweiterbar. Das Delegate kümmert sich um die Anpassung und Erweiterung, indem es dem delegierenden Objekt an bestimmten Stellen Hinweise zum konkreten Verhalten gibt oder zusätzliche Funktionen ausführen kann.

Im engeren Sinn ist es zwar immer so, dass das delegierende Objekt Nachrichten an das Delegate schickt und nur selten andersherum. Allerdings ist es sehr oft so, dass das Delegate dasjenige Objekt ist, das das delegierende Objekt überhaupt erst erzeugt und nutzt. Typisches Beispiel: Controller sind oft die Delegates von Views.

Na, ja, blindlings werden die nicht veschickt (@optional) und eine Hierarchie gibt es schon.

Man begreift das vielleicht am einfachsten, wenn man sich den Zweck überlegt:

Ganz häufig kommt es vor, dass eine Klasse abstrakt eine Möglichkeit (Methode) anbietet, die sich aber nicht abstrakt implementieren lässt oder dies geht zwar, man möchte das aber ändern. Denk dir die abstrakte Klasse NSView, die ein -drawRect: hat. Sie hat das, weil sie sich immer zeichnen kann (sonst wäre es kein View). Sie kann aber nichts zeichnen, weil sich jeder View anders malt.

Häufig löst man das mit Ableitungen: MyView : NSView und überschreibt dann -drawRect:. Das ist in diesem Beispiel auch ganz gut. Es gibt da bloß zwei Probleme:

1. In einer Subklasse erhalte ich viel mehr Information als ich brauche (White-Boxing). So können etwa Objekte der Subklasse regelmäßig auf Instanzvariablen, die in der Basisklasse definiert sind, zugreifen. Das will man aber nicht. Auch bleibt unklar, welche Methoden sinnvoll überschrieben werden können und welche nicht. Man kann diese Probleme noch einigermaßen mit Technologien (private Instanzvariablen, virtuelle Methoden) lösen. Aber bei komplizierten Abhängigkeiten geht das nicht mehr. Und es ist ebenfalls nicht möglich, eine von vielen Methoden zur Ableitung anzubieten (virtual -a, wenn nicht implementiert, dann eben virtual -b usw.) Ode res gibt veschiedene Themenbereiche: a) Zeichnen, b) Eventhandling Auch gehen verschiedene Tehemenbereiche nicht. So kann man etwa nicht eine Basisklasse ableiten für das Eventhandling, für das Zeichenhandling und noch für die Datenbeschaffung. Das muss dann in einer einzigen Ableitung geschehen, obwohl die ja eigentlich unabhängig ist.

2. Häufig ist es zudem so, dass die Funktionaität, die man in der Ableitung programmieren muss, gar nicht mehr zum View gehört. Denke an den hier genannten Tableview. Da wird nun eine neue Zeile selektiert. Schön blau malen gehört zum View, keine Frage. Aber, ob eine bestimmte Zeile selektierbar ist, ist eine Frage der Darstellung, sondern der Ablaufsteuerung. Macht man das in einer Subklasse etwa mit einer überschriebenen Methode -canSelectRow: so holt man sich Controllerfunktionaöität in die Viewschicht. Eklig, weil so viele Viewcontroller-Subklassen entstehen.

Beim Delegating lösen sich diese Probleme:

1. Da ein Delegate ein anderes Objekt ist, erhält es keine "inneren" Informationen vom delegierenden Objekt.Die Kapselung bleibt erhalten und es gibt eine definierte API (Black-Boxing). Man kann komplexe Abfragen dazu bauen wie: Wenn die Delegateklasse dieses nicht implementiert, dann nimm dieses. Ebenfalls ist es möglich, verschiedene Delegates anzubieten, die dann in einer Delegateklasse implmentiert sien können oder in mehreren, wobei beliebige Kombinationen möglich sind.

2. Da ein Delegate ein anderes Objekt ist, kann es ein Controllerobjekt sein. Damit hast du ein Objekt von einer Controllerklasse (Delegate) und ein Objekt von einer Viewklasse (Delegierer) und alles bleibt schon sauber getrennt.

Du kannst dir das So vorstellen
Ableitung:
Basisklasse -> Subklasse
virtuelle Methode -> überschriebene Methode

Delegating:
Basisklasse, Delegateklasse
Protokollmethode, Delegatemethode