NSProxy vs NSObject

Question

Ich verwendete Methode swizzling, um alle Methodenaufrufe in einer Klasse mit zusätzlicher Funktionalität zu umbrechen. Insbesondere war ich:

• prüfen, ob das erforderliche Objekt für diesen Aufruf Methode im Cache war
• Wenn der Cache das Objekt hatte es zurück.
• Wenn nicht, senden Sie die ursprüngliche Implementierung, füllen Sie den Cache und geben Sie diesen zurück.

Für jede Methode würde ich auf eine empfohlene Methode umleiten. Und implementieren Sie die neue Methode mit + (BOOL) resolveInstanceMethod: (SEL) sel und IMP_implementationWithBlock.

Es funktionierte gut, aber der Code nicht gut gelesen. Es scheint, dass NSProxy einen besseren Weg bietet, diese Funktionalität zu implementieren.

Aber noch eine andere Alternative wäre, einfach eine NSObject-Unterklasse Stand-in und abfangen Methodenaufrufe um die Methoden meines Zielobjekts zu haben. Indem ich forwardInvocation und methodSignatureForSelector überschreibe, kann ich das gewünschte Ergebnis erhalten.

Was gibt mir NSProxy? Warum sollte ich das stattdessen verwenden?

Answer 1

Der Punkt von NSProxy ist, dass es die meisten Methoden nicht implementiert. Dies ist erforderlich, um sicherzustellen, dass die Objective-C-Weiterleitung zuerst aufgerufen wird. Wenn Sie mit NSObject beginnen, gibt es eine Menge Methoden, die nur direkt versandt werden, ohne dass Sie die Möglichkeit haben, sie weiterzuleiten.