The rename transformation is the simplest and most flexible. It will rename any of the following:

To rename a symbol, follow these steps:

All of the rename transformations occur within the symbol's scope. For example, renaming an integer variable from c to i, as shown in Figure 10-3, only renames references that refer to the selected variable. Refactor is not confused by the unichar c variable, even though it is nested within the block of code where int c is declared. In this respect, refactoring is more intelligent than the Edit All in Scope command described in the "Editing Symbol Names" section of Chapter 7. Edit All in Scope only analyzes the textual context, and would have renamed both c variables to i.

Figure 10-3. FIGURE 10-3

Renaming method signatures is particularly accurate and flexible. For example, when renaming an Objective-C method name, Xcode picks up the entire method signature and asks that you supply a replacement. You can change any, or all, of the method name tokens and the refactoring tool will make the appropriate changes in the code. In the example shown in Figure 10-4, the method scheduleDate:time:room: is being renamed to scheduleStartingAt:duration:room:. The replacement method name must match the number and order of the original arguments.

Figure 10-4. FIGURE 10-4

When renaming a class, you are given the additional option of renaming any source files with the same name. By tradition, the files that define the Hue class are named Hue.h and Hue.m. Renaming the Hue class to Color would also rename the files to Color.h and Color.m, and update any #include "Hue.h" and #import "Hue.m" statements to match.

The Rename Related KVC/Core Data Members option extends the refactoring beyond the scope of your source code. It scours NIB documents and Core Data models for any references to the class, method, or variable being remained. This option will update class inheritance, member names, outlet connections, actions, and bindings. If you have any NIB document or Core Data models that refer to your class, I highly recommend checking this option.

Reusable, modular code is the hallmark of efficient programming. Often, however, code that could be organized into its own method or function is originally embedded in a larger function — often because you don't realize its utility until later. Take the situation shown in Listing 10-1. Here, the programmer is writing a new rescheduleStartingAt:duration: method, when she realizes that the loop she is about to write is identical to the one in scheduleStartingAt:duration:inRoom:.

- (void)scheduleStartingAt:(NSDate*)date
                  duration:(NSTimeInterval)minutes
                    inRoom:(RoomIdentifier)roomID
{
    start = date;
    duration = minutes*60.0;
    room = roomID;
    NSEnumerator *e = [participants objectEnumerator];
    Person *participant;
    while ( (participant=[e nextObject])!=nil ) {
        [participant updateCalendarEvent:self];
    }
}

- (void)rescheduleStartingAt:(NSDate*)date
                    duration:(NSTimeInterval)minutes
{
    start = date;
    duration = minutes*60.0;
    NSEnumerator *e =
}

Ideally, the loop that sends update events to all of the meeting participants should be isolated in its own method. Then, rescheduleStartingAt:duration: and scheduleStartingAt:duration:inRoom: can reuse the logic. This transformation is called an extraction.

To extract a block of code, follow these steps:

Figure 10-5 illustrates our programmer exacting the enumeration loop in Listing 10-1 into its own method.

The extract transformation lifts a local fragment of code and puts it into its own Objective-C method or C function (your choice). In the example shown in Figure 10-5, our programmer is extracting the enumeration loop into a new method named -(void)updateParticipants. The original code is replaced with a message that invokes the new method. After the extraction, the rescheduleStartingAt:duration: can now be completed with a single [self updateParticipants]; statement.

Figure 10-5. FIGURE 10-5

When extracting code, Xcode analyzes the scope of all of the variable references within the code block. Any variable that isn't in scope when the code is relocated to its own method (or function) is converted into a parameter. In the previous example, both the participants and self instance variables are still accessible in the new updateParticipants method. If you choose to extract this code into a C function, or the loop refers to any automatic variables declared earlier in the method, those references will be converted into parameters, as shown in Figure 10-6.

Figure 10-6. FIGURE 10-6

The function notify_participants(...) in Figure 10-6 has no object context, so the collection of participants and the receiving object were converted to parameters.

The encapsulate transformation creates getter and setter methods for class instance variables. Figure 10-7 shows the tasks variable being encapsulated.

Figure 10-7. FIGURE 10-7

To encapsulate an instance variable, follow these steps:

The encapsulate transformation generates a getter and setter method for the instance variable and then replaces any existing references to the variable with messages (that is, ivar with [object ivar] and ivar=... with [object setIvar:...]).

As of this writing, a number of unfortunate limitations keep the encapsulate transformation from being truly useful, except in a narrow set of circumstances. For the specifics, see the "Encapsulate" portion of the "Refactoring Pitfalls" section, later in this chapter.

Because of these issues, I recommend using the encapsulate transformation only when:

In any other circumstances, I'd recommend using Objective-C @property and @synthesize directives instead. See the "Updating a Project to Objective-C 2.0" section later in this chapter.

The create superclass transformation creates a new class definition and inserts it between an existing class and its original superclass. This is most useful when you need to create a more abstract superclass for an existing class whose functionality needs to be partitioned. To create a superclass, follow these steps:

Xcode changes the inheritance of the existing class so that it is now a subclass of the new class, which is a subclass of the original superclass. If you asked Xcode to generate new class files, those files are added to the project and appropriate #import directives are inserted into the original files, as shown in Figure 10-8.

Figure 10-8. FIGURE 10-8

In the hypothetical project management program, you decide that you need an intermediate class between the very abstract Event class and the very specific Meeting class. The create superclass transformation quickly defines a new ScheduledMeeting class, changes the superclass of the Meeting class, and then creates and adds all the necessary project files.

After applying a create superclass transformation, or simply creating a new subclass, you may want to migrate properties or functionality from a class to its superclass or vice versa. That's what the move up and move down transformations do.

To move an instance variable or method to a superclass or one of its subclasses, follow these steps:

Using the project management example again, the start and duration properties in the Meeting class need to be migrated to the new ScheduledEvent superclass, as shown in Figure 10-9.

Figure 10-9. FIGURE 10-9

This transformation is rarely without consequences; you must migrate the instance variables start and duration, along with any related methods, one at a time. This will also require that some of the methods be recoded, and you'll probably want to create an abstract scheduleStartingAt:duration: method in the new superclass. You could do this using two transformations: extract the code that sets the schedule in scheduleStartingAt:duration:inRoom: into its own method, then perform a move up transformation to migrate it to the ScheduledEvent superclass.

Objective-C introduces the much-appreciated fast enumeration syntax. Fast enumeration provides a succinct syntax for processing the objects in a collection that's both fast and robust. Prior to Objective-C 2.0, programmers used a variety of for and while loop patterns. The modernize loop transformation attempts to convert a legacy for or while loop into its equivalent using fast enumeration syntax.

To modernize a single loop, follow these steps:

The process begins by selecting the entire for loop statement and block, as shown in Figure 10-10.

Figure 10-10. FIGURE 10-10

Loop modernization only transforms for loops that meet these criteria:

When the modernize loop transformation updates a while loop, it replaces the traditional NSEnumerator pattern shown in Figure 10-11 with its modern equivalent.

Figure 10-11. FIGURE 10-11

Loop modernization only transforms while loops that meet these criteria:

The second and third points mean that you can't use refactoring to modernize a loop that uses -reverseObjectEnumerator.

NSEnumerator* e = [collection reverseObjectEnumerator];
for ( id obj in e ) {
...
}