Approach

For this example, you’ll actually develop two projects. In one project, you’ll code the program that uses a loadable bundle, and in the other project, you’ll create the loadable bundle. You’ll proceed as follows:

1. In Project 1, develop a protocol and a class that conforms to this protocol.
2. In Project 2, develop a loadable bundle comprised of a different class conforming to this protocol.
3. In Project 1, use the NSBundle class to find and load this bundle, create an object from a class in the bundle (developed in step 2), and then invoke a method on this object.

Sounds like fun, right? OK, let’s get started!

Step 1: Laying the Foundation

In Xcode, create a new project by selecting New Project … from the Xcode File menu. In the New Project Assistant pane, create a command-line application. In the Project Options window, specify DynaLoader for the Product Name, choose Foundation for the Project Type, and select ARC memory management by selecting the Use Automatic Reference Counting check box. Specify the location in your file system where you want the project to be created (if necessary, select New Folder and enter the name and location for the folder), uncheck the Source Control check box, and then click the Create button.

Now you’re going to create a protocol and a class that conforms to the protocol. You probably recall from Chapter 2 that a protocol declares methods and properties that can be implemented by any class. Combined with dynamic typing, this provides an idea mechanism for specifying a set of methods implemented by a class that is dynamically loaded from a bundle. Select New File … from the Xcode File menu, select the Objective-C protocol template, name the protocol Greeter, select the DynaLoader folder for the files location and the DynaLoader project as the target, and then click the Create button. A header file named Greeter.h has been added to the Xcode project navigator pane. Click this file to display the Greeter protocol (see Listing 9-1).

Listing 9-1.  Greeter Protocol Template File

#import <Foundation/Foundation.h>

@protocol Greeter <NSObject>

@end

In the editor pane, update the Greeter.h file as shown in Listing 9-2.

Listing 9-2.  Greeter Protocol Updates

#import <Foundation/Foundation.h>

@protocol Greeter <NSObject>

- (NSString *) greeting:(NSString *)salutation;

@end

This protocol declares a method named greeting that takes an NSString pointer as its parameter and returns an NSString pointer. Now let’s implement a class that conforms to the Greeter protocol. Select New File … from the Xcode File menu, select the Objective-C class template, name the class BasicGreeter (select NSObject in the Subclass of drop-down list), select the DynaLoader folder for the files location and the DynaLoader project as the target, and then click the Create button. Next, in the Xcode project navigator pane, select the resulting header file named BasicGreeter.h and update the interface as shown in Listing 9-3.

Listing 9-3.  BasicGreeter Interface

#import <Foundation/Foundation.h>
#import "Greeter.h"

@interface BasicGreeter : NSObject <Greeter>

@end

The template BasicGreeter interface has been updated to adopt the Greeter protocol; now select the BasicGreeter.m file and update the implementation as shown in Listing 9-4.

Listing 9-4.  BasicGreeter Implementation

#import "BasicGreeter.h"

@implementation BasicGreeter

- (NSString *) greeting:(NSString *)salutation
{
  return [NSString stringWithFormat:@"%@, World!", salutation];
}

@end

The BasicGreeter implementation defines the greeting: method (and thus conforms to the Greeter protocol), returning a text string that begins with the method’s input parameter. Now let’s test this class. Select the main.m file and update the main() function, as shown in Listing 9-5.

Listing 9-5.  BasicGreeter main() Function

#import <Foundation/Foundation.h>
#import "BasicGreeter.h"

int main(int argc, const char * argv[])
{
  @autoreleasepool
  {
    id<Greeter> greeter = [[BasicGreeter alloc] init];
    NSLog(@"%@", [greeter greeting:@"Hello"]);
  }
  return 0;
}

First, the function creates a BasicGreeter object and assigns it to a variable named greeter. This variable is declared to be of type id and conforms to the Greeter protocol. It then invokes the greeting: method on the object, and logs the result in the output pane. By declaring the variable as

id<Greeter> greeter

it can be assigned to any Objective-C object that conforms to the Greeter protocol. If you compile and run the program now, the output pane displays “Hello, World!” (see Figure 9-1).

Great! You have completed step 1. Now you will create another class that conforms to the Greeter protocol, this time packaged in a loadable bundle.

Step 2: Creating a Loadable Bundle

Xcode makes it easy to create a loadable bundle. It’s simply another type of project. First, create a new project by selecting New Project … from the Xcode File menu. In the New Project Assistant pane under OS X, select Framework & Library, and then select Bundle (see Figure 9-2).

Next, in the Project Options window, specify CustomGreeter for the Product Name, an Organization Name (optional value), and a Company Identifier (the default value is fine, but any name will suffice). Select Cocoa for the Framework the bundle will link against, and select ARC memory management by checking the Use Automatic Reference Counting check box. Specify the location in your file system where you want the project to be created (if necessary, select New Folder and enter the name and location for the folder), uncheck the Source Control check box, do not add to any project or workspace, and then click the Create button. The workspace window shown in Figure 9-3 is displayed.

Cool. Xcode created an empty bundle. In the project navigator pane under the Products group, notice the CustomGreeter.bundle file. This is the bundle to which you’ll add your code and resources. Also note the CustomGreeter-Info.plist file. It is a required file that contains information about the bundle’s configuration. Now let’s add a class to this bundle that implements the Greeter protocol. First, you need to include the Greeter.h header file in the bundle. Fortunately, Xcode provides a simple mechanism for importing files into a project. Hold down the Ctrl key and (from the Xcode project navigator pane) select the CustomGreeter project. A drop-down window then displays a set of options. Select the Add Files to “CustomGreeter” … option (see Figure 9-4).

The Greeter.h file is located under the DynaLoader project folder that you created in step 1. Navigate to this project folder, select the file, and click the Add button (see Figure 9-5) to add it to the CustomGreeter bundle.

Now add a new class to the bundle that conforms to this protocol. Select New File … from the Xcode File menu, select the Objective-C class template, name the class CustomGreeter (select NSObject in the Subclass of drop-down list), select the CustomGreeter folder for the files location and the CustomGreeter project as the target, and then click the Create button. In the Xcode project navigator pane, select the resulting header file named CustomGreeter.h and update the interface, as shown in Listing 9-6.

Listing 9-6.  CustomGreeter Interface

#import <Foundation/Foundation.h>
#import "Greeter.h"

@interface CustomGreeter : NSObject <Greeter>

@end

As with the BasicGreeter class, the template CustomGreeter interface has been updated to adopt the Greeter protocol. Now select the CustomGreeter.m file and update the implementation as shown in Listing 9-7.

Listing 9-7.  CustomGreeter Implementation

#import "CustomGreeter.h"

@implementation CustomGreeter

- (NSString *) greeting:(NSString *)salutation
{
  return [NSString stringWithFormat:@"%@, Universe!", salutation];
}

@end

The CustomGreeter implementation defines the greeting: method (and thus conforms to the Greeter protocol), returning a text string that begins with the method’s input parameter. Now compile the bundle by selecting Build from the Xcode Product menu. And that’s it—you’ve created a loadable bundle that includes a class (CustomGreeter) that conforms to the Greeter protocol. In the Xcode project navigator pane, note the CustomGreeter.bundle file in the Products group. Select this bundle file and note in the Xcode file inspector (on the right side of the Xcode workspace window) the full path shown in Figure 9-6. This indicates the path to the CustomGreeter.bundle file that you’ll need when you load the bundle using the NSBundle class.

Step 3: Dynamically Loading the Bundle

Now that you have created a loadable bundle, let’s use it to dynamically create an object (from a bundle class) and invoke a method on it. In Xcode, return to the DynaLoader project, select the main.m file in the project navigator pane, and update the main() function as shown in Listing 9-8.

Listing 9-8.  Using NSBundle to Load a Bundle

#import <Foundation/Foundation.h>
#import "BasicGreeter.h"

int main(int argc, const char * argv[])
{
  @autoreleasepool
  {
    id<Greeter> greeter = [[BasicGreeter alloc] init];
    NSLog(@"%@", [greeter greeting:@"Hello"]);
     
    // Now create a bundle at the specified path (retrieved from input argument)
    NSString *bundlePath;
    if (argc != 2)
    {
      // No bundle path provided, exit
      NSLog(@"Please provide a path for the bundle");
    }
    else
    {
      bundlePath = [NSString stringWithUTF8String:argv[1]];
      NSBundle *greeterBundle = [NSBundle bundleWithPath:bundlePath];
      if (greeterBundle == nil)
      {
        NSLog(@"Bundle not found at path");
      }
      else
      {
        // Dynamically load bundle
        NSError *error;
        BOOL isLoaded = [greeterBundle loadAndReturnError:&error];
        if (!isLoaded)
        {
          NSLog(@"Error = %@", [error localizedDescription]);
        }
        else
        {
          // Bundle loaded, create an object using bundle and send it a message
          Class greeterClass = [greeterBundle classNamed:@"CustomGreeter"];
          greeter = [[greeterClass alloc] init];
          NSLog(@"%@", [greeter greeting:@"Hello"]);
           
          // Done with dynamically loaded bundle, now unload it
          // First release any objects whose class is defined in the bundle!
          greeter = nil;
          BOOL isUnloaded = [greeterBundle unload];
          if (!isUnloaded)
          {
            NSLog(@"Couldn't unload bundle");
          }
        }
      }
    }
  }
  return 0;
}

I know, you added a lot of code here, but don’t worry. You’ll take this one step at a time. Functionally, the updates implement the following logic:

1. Retrieve the bundle path argument
2. Create an NSBundle object
3. Load the bundle
4. Get a bundle class
5. Unload the bundle
6. Set the bundle path argument

Let’s discuss the code for each of these in turn.

int main(int argc, const char * argv[])

> DynaLoader /CustomGreeter.bundle

NSString *bundlePath;
if (argc != 2)
{
  // No bundle path provided, exit
  NSLog(@"Please provide a path for the bundle");
}
else
{
  bundlePath = [NSString stringWithUTF8String:argv[1]];

+ (NSBundle *) bundleWithPath:(NSString *) fullPath;

bundlePath = [NSString stringWithUTF8String:argv[1]];
NSBundle *greeterBundle = [NSBundle bundleWithPath:bundlePath];
if (greeterBundle == nil)
{
  NSLog(@"Bundle not found at path");
}

- (BOOL)loadAndReturnError:(NSError **) error;

NSError *error;
BOOL isLoaded = [greeterBundle loadAndReturnError:&error];
if (!isLoaded)
{
  NSLog(@"Error = %@", [error localizedDescription]);
}

Class greeterClass = [greeterBundle principalClass];
greeter = [[greeterClass alloc] init];
NSLog(@"%@", [greeter greeting:@"Hello"]);

greeter = nil;
BOOL isUnloaded = [greeterBundle unload];
if (!isUnloaded)
{
  NSLog(@"Couldn't unload bundle");
}

Defining a Method Implementation

As you saw in Chapter 8, an Objective-C method is simply a C-language function that takes at least two arguments: self and _cmd. Immediately after the import statements, the code in Listing 9-9 defines a function that you’ll use to add a method to a class.

// Method implementation function for the display selector
static void display(id self, SEL _cmd)
{
  NSLog(@"Invoking method with selector %@ on %@ instance",
        NSStringFromSelector(_cmd), [self className]);
}

Creating and Registering a Class

To dynamically create a class with the runtime APIs, you must perform the following steps:

1. Create a new class and metaclass.
2. Add methods and instance variables to the class (if any).
3. Register the newly created class.

This functionality is implemented with the following code from Listing 9-9.

// Create a class pair
Class WidgetClass = objc_allocateClassPair([NSObject class], "Widget", 0);
     
// Add a method to the class
const char *types = "v@:";
class_addMethod(WidgetClass, @selector(display), (IMP)display, types);
     
// Add an ivar to the class
const char *height = "height";
class_addIvar(WidgetClass, height, sizeof(id), rint(log2(sizeof(id))),
              @encode(id));
     
// Register the class
objc_registerClassPair(WidgetClass);

The runtime class_addMethod function takes as arguments the class to which the method should be added, the selector that specifies the name of the method being added, the function that implements the method, and a character string—known as type encodings—that describes the types of arguments and the return value of the method. Each possible type is represented by a type code; for example, the character “v” is the code for a void, “@” is the code for an object (whether a pointer to an Objective-C class or the id type), and “:” is the code for the SEL type. The complete list of type encodings are specified in the Apple Objective-C Runtime Programming Guide. The codes in the types parameter of the class_addMethod must be arranged in a defined order: the first code is for the return type, the second code is for method’s implicit self parameter (the id type), the third code is for the type of the method’s implicit _cmd parameter (the SEL type), and the remaining codes are for the types of each of the explicit parameters of the method. Thus for the display method, the corresponding types array has a value of “v@:.”

Creating a Class Instance

The code creates an instance of the dynamically added class, sets its instance variable to a value, and then invokes the instance method. It also logs messages to the output pane to show the instance variable value and the method invocation.

Dynamically Adding a Variable to a Class Instance

Objective-C does not provide the capability for adding instance variables to an object; however, a feature of the runtime—associated objects—can be used to effectively mimic this functionality. An associated object is an object that is attached to a class instance, referenced by a key. This can be used in a variety of scenarios; for example, with Objective-C categories that don’t permit instance variables. When you create an associated object, you specify the key mapped for the association, the memory management policy for the associated object, and its value. The following code from Listing 9-9 demonstrates use of the runtime APIs for associated objects.

// Dynamically add a variable (an associated object) to the widget
NSNumber *width = [NSNumber numberWithInt:10];
objc_setAssociatedObject(widget, @"width", width,
                         OBJC_ASSOCIATION_RETAIN_NONATOMIC);
     
// Retrieve the variable's value and display it
id result = objc_getAssociatedObject(widget, @"width");
NSLog(@"Widget instance width = %@", result);

The runtime APIs include an enum that lists the possible values for the memory management policy. In this policy, OBJC_ASSOCIATION_RETAIN_NONATOMIC, assigns a nonatomic strong reference to the associated object. This is similar to creating a property with the attributes nonatomic, strong. When you compile and run the RuntimeWidget program, you should observe the messages in the output pane shown in Figure 9-12.

This example demonstrates how to use the runtime APIs to dynamically create classes, class instances, and associated objects. Please refer to the Apple Objective-C Runtime Reference for the complete guide to the runtime APIs.

Creating the Invoker Protocol

In Xcode, create a new project by selecting New Project … from the Xcode File menu. In the New Project Assistant pane, create a command-line application. In the Project Options window, specify AspectProxy for the Product Name, choose Foundation for the Project Type, and select ARC memory management by checking the Use Automatic Reference Counting check box. Specify the location in your file system where you want the project to be created (if necessary, select New Folder and enter the name and location for the folder), uncheck the Source Control check box, and then click the Create button.

Now you’re going to create a protocol and a class that conforms to the protocol. Select New File … from the Xcode File menu, select the Objective-C protocol template, name the protocol Invoker, select the AspectProxy folder for the files location and the AspectProxy project as the target, and then click the Create button. A header file named Invoker.h has been added to the Xcode navigator pane. In the editor pane, update the Greeter.h file, as shown in Listing 9-10.

Listing 9-10.  Invoker Protocol

#import <Foundation/Foundation.h>

@protocol Invoker <NSObject>

// Required methods (must be implemented)
@required
- (void) preInvoke:(NSInvocation *)inv withTarget:(id) target;
// Optional methods
@optional
- (void) postInvoke:(NSInvocation *)inv withTarget:(id) target;

@end

This protocol declares two methods. preInvoke:withTarget: is a required method (it must be implemented by any class that conforms to this protocol) that implements cross-cutting functionality performed immediately prior to invoking the method on the real object. The method named preInvoke:withTarget: is an optional method that implements cross-cutting functionality performed immediately after invoking the method on the real object.

Now you’ll implement a class that conforms to this protocol, implementing the desired cross-cutting functionality. Select New File … from the Xcode File menu, select the Objective-C class template, name the class AuditingInvoker (select NSObject in the Subclass of drop-down list), select the AspectProxy folder for the files location and the AspectProxy project as the target, and then click the Create button. In the Xcode navigator pane, select the resulting header file named AspectProxy.h and update the interface as shown in Listing 9-11.

Listing 9-11.  AuditingInvoker Interface

#import <Foundation/Foundation.h>
#import "Invoker.h"

@interface AuditingInvoker : NSObject <Invoker>

@end

The template AuditingInvoker interface has been updated to adopt the Invoker protocol. Now select the AuditingInvoker.m file and update the implementation as shown in Listing 9-12.

Listing 9-12.  AuditingInvoker Implementation

#import "AuditingInvoker.h"

@implementation AuditingInvoker

- (void) preInvoke:(NSInvocation *)inv withTarget:(id)target
{
  NSLog(@"Creating audit log before sending message with selector %@ to %@ object",
        NSStringFromSelector([inv selector]), [target className]);
}

- (void) postInvoke:(NSInvocation *)inv withTarget:(id)target
{
  NSLog(@"Creating audit log after sending message with selector %@ to %@ object",
        NSStringFromSelector([inv selector]), [target className]);
}

@end

The AuditingInvoker implementation defines the preInvoke:withTarget: and the postInvoke:withTarget: methods, and thus it conforms to the Invoker protocol. The methods merely log appropriate messages to the Xcode output pane. OK, now that you’re done implementing the cross-cutting functionality, let’s tackle the NSProxy subclass.

Coding the Proxy Class

Now you’re going to create the proxy class. It will subclass NSProxy and implement the message forwarding methods forwardInvocation: and methodSignatureForSelector:. Select New File … from the Xcode File menu, select the Objective-C class template, name the class AspectProxy (select NSObject in the Subclass of drop-down list), select the AspectProxy folder for the files location and the AspectProxy project as the target, and then click the Create button. In the Xcode navigator pane, select the resulting header file named AspectProxy.h and update the interface as shown in Listing 9-13.

Listing 9-13.  AspectProxy Interface

#import <Foundation/Foundation.h>
#import "Invoker.h"

@interface AspectProxy : NSProxy

@property (strong) id proxyTarget;
@property (strong) id<Invoker> invoker;
@property (readonly) NSMutableArray *selectors;

- (id)initWithObject:(id)object andInvoker:(id<Invoker>)invoker;
- (id)initWithObject:(id)object selectors:(NSArray *)selectors
          andInvoker:(id<Invoker>)invoker;
- (void)registerSelector:(SEL)selector;

@end

The interface adds three properties and three methods. The proxyTarget property is the real object to which messages are forwarded through the NSProxy instance. The invoker property is an instance of a class (which conforms to the Invoker protocol) that implements the cross-cutting functionality desired. The selectors property is a collection of selectors that define the messages on which the cross-cutting functionality will be invoked. Two of the methods are initialization methods for an AspectProxy class instance, and the third method, registerSelector:, is used to add a selector to the current list. Now select the AspectProxy.m file and update the implementation as shown in Listing 9-14.

Listing 9-14.  AspectProxy Implementation

#import "AspectProxy.h"

@implementation AspectProxy

- (id)initWithObject:(id)object selectors:(NSArray *)selectors
          andInvoker:(id<Invoker>)invoker
{
  _proxyTarget = object;
  _invoker = invoker;
  _selectors = [selectors mutableCopy];
  return self;
}

- (id)initWithObject:(id)object andInvoker:(id<Invoker>)invoker
{
  return [self initWithObject:object selectors:nil andInvoker:invoker];
}

- (NSMethodSignature *)methodSignatureForSelector:(SEL)sel
{
  return [self.proxyTarget methodSignatureForSelector:sel];
}

- (void)forwardInvocation:(NSInvocation *)inv
{
  // Perform functionality before invoking method on target
  if ([self.invoker respondsToSelector:@selector(preInvoke:withTarget:)])
  {
    if (self.selectors != nil)
    {
      SEL methodSel = [inv selector];
      for (NSValue *selValue in self.selectors)
      {
        if (methodSel == [selValue pointerValue])
        {
          [[self invoker] preInvoke:inv withTarget:self.proxyTarget];
          break;
        }
      }
    }
    else
    {
      [[self invoker] preInvoke:inv withTarget:self.proxyTarget];
    }
  }

  // Invoke method on target
  [inv invokeWithTarget:self.proxyTarget];
   
  // Perform functionality after invoking method on target
  if ([self.invoker respondsToSelector:@selector(postInvoke:withTarget:)])
  {
    if (self.selectors != nil)
    {
      SEL methodSel = [inv selector];
      for (NSValue *selValue in self.selectors)
      {
        if (methodSel == [selValue pointerValue])
        {
          [[self invoker] postInvoke:inv withTarget:self.proxyTarget];
          break;
        }
      }
    }
    else
    {
      [[self invoker] postInvoke:inv withTarget:self.proxyTarget];
    }
  }
}

- (void)registerSelector:(SEL)selector
{
  NSValue* selValue = [NSValue valueWithPointer:selector];
  [self.selectors addObject:selValue];
}

@end

The initialization methods initialize an AspectProxy object instance accordingly. Note that as NSProxy is a base class, there is no call to [super init] at the beginning of these methods. The registerSelector: method adds another selector to the collection, as mentioned earlier. The implementation of methodSignatureForSelector: returns an NSMethodSignature instance for the method to be invoked on the target object. The runtime system requires that this method be implemented when performing normal forwarding. The implementation of forwardInvocation: invokes the method on the target object and conditionally invokes the AOP functionality if the selector for the method invoked on the target object matches one of the selectors registered in the AspectProxy object. Whew. When you’ve had enough time to digest this, let’s move on to the main.m file and test out your program!

Testing the AspectProxy

Let’s test the AspectProxy, but first let’s add a target class to the proxy. You’ll use the Calculator class that you implemented in Chapter 7. It declares the following methods:

- (NSNumber *) sumAddend1:(NSNumber *)adder1 addend2:(NSNumber *)adder2;
- (NSNumber *) sumAddend1:(NSNumber *)adder1 :(NSNumber *)adder2;

As you learned earlier in this chapter, Xcode provides a simple mechanism for importing files into a project. Hold down the Ctrl key and (from the Xcode project navigator pane) select the AspectProxy project. A drop-down window displays a set of options. Select the Add Files to “AspectProxy” … option. Navigate over to the Calculator project folder, select the Calculator.h and Calculator.m files, and click the Add button to add them to your AspectProxy project. OK, now with that done, let’s update the main()function to create a calculator proxy and invoke its methods, causing the AOP AuditingInvoker methods to be invoked as well. In the project navigator pane, select the main.m file and update it as shown in Listing 9-15.

Listing 9-15.  AspectProxy main() Function

#import <Foundation/Foundation.h>
#import "AspectProxy.h"
#import "AuditingInvoker.h"
#import "Calculator.h"

int main(int argc, const char * argv[])
{
  @autoreleasepool
  {
    // Create Calculator object
    id calculator = [[Calculator alloc] init];
    NSNumber *addend1 = [NSNumber numberWithInteger:-25];
    NSNumber *addend2 = [NSNumber numberWithInteger:10];
    NSNumber *addend3 = [NSNumber numberWithInteger:15];

    // Create proxy for object
    NSValue* selValue1 = [NSValue valueWithPointer:@selector(sumAddend1:addend2:)];
    NSArray *selValues = @[selValue1];
    AuditingInvoker *invoker = [[AuditingInvoker alloc] init];
    id calculatorProxy = [[AspectProxy alloc] initWithObject:calculator
                                                   selectors:selValues
                                                  andInvoker:invoker];
     
    // Send message to proxy with given selector
    [calculatorProxy sumAddend1:addend1 addend2:addend2];

    // Now send message to proxy with different selector, no special processing!
    [calculatorProxy sumAddend1:addend2 :addend3];
     
    // Register another selector for proxy and repeat message
    [calculatorProxy registerSelector:@selector(sumAddend1::)];
    [calculatorProxy sumAddend1:addend1 :addend3];
     
  }
  return 0;
}

First, the code creates a Calculator object and some data values. Next, it creates a proxy for the Calculator object, initializing it with a selector for the sumAddend1:addend2: method and an AuditingInvoker instance. Notice the following statement:

NSArray *selValues = @[selValue1];

The notation @[] is used to create an array literal. In Part 4 of this book, you’ll examine Objective-C literals in depth. The sumAddend1:addend2: message is sent to the proxy. This causes the proxy to perform the AOP functionality of the AuditingInvoker instance in addition to the method on the Calculator object. Next, the sumAddend1:: message is sent to the proxy; because this method is not yet registered on the proxy when it is invoked, the AOP functionality is not performed. Finally, the sumAddend1:: selector is added to the proxy and the message is resent to the proxy; because the selector is now registered, the AOP functionality is now performed. When you compile and run the AspectProxy program, you should observe the messages in the output pane shown in Figure 9-14.

Observe from the messages in the output pane that invoking the sumAddend1:addend2: method on the calculator proxy results in the proxy calling the preInvoke: method on the AuditorInvoker object, followed by the target method sumAddend1:addend2: method on the real subject (Calculator object), and finally the postInvoke: method on the AuditorInvoker object. Because the sumAddend1:addend2: method was registered with the calculator proxy, this matches the expected behavior. Next, the sumAddend1:: method is invoked on the calculator proxy. Because this method is not registered with the proxy, it only forwards this method call to the Calculator object, and does not call the AuditorInvoker methods. Finally, the sumAddend1:: method is registered with the proxy and the method is called again. This time, it calls the AOP methods on the AuditorInvoker object and the sumAddend1:: method on the real subject, as expected.