title: NSProxy vs NSObject
body: <p>I was using method swizzling to wrap all method invocations in a class with some extra functionality. Specifically I was:</p>
  
  <ul>
  <li>Checking if the required object for this method call was in the cache</li>
  <li>If the cache had that object return it. </li>
  <li>If not, dispatch to the original implementation, populate the cache and return that. </li>
  </ul>
  
  <p>For each method, I would reroute to an advised method. And implement the new method using + (BOOL)resolveInstanceMethod:(SEL)sel and IMP_implementationWithBlock. </p>
  
  <p>It worked fine, but the code didn't read nicely. It seems NSProxy will provide a neater way to implement this functionality. </p>
  
  <p>But still another alternative, would be to simply have an NSObject subclass stand-in and intercept method calls around my target object's methods. By overriding forwardInvocation and methodSignatureForSelector, I can get the required outcome. </p>
  
  <p>So what does NSProxy give me? Why should I use this instead? </p>