Categories and Extensions

A category allows you to add methods to an existing class—even to one to which you do not have the source. This is a powerful feature that allows you to extend the functionality of existing classes without subclassing. Using categories, you can also split the implementation of your own classes between several files. Class extensions are similar, but allow additional required API to be declared for a class in locations other than within the primary class @interface block

Contents:

Adding Methods to Classes
How you Use Categories
Categories of the Root Class
Extensions

Adding Methods to Classes

You can add methods to a class by declaring them in an interface file under a category name and defining them in an implementation file under the same name. The category name indicates that the methods are additions to a class declared elsewhere, not a new class. You cannot, however, use a category to add additional instance variables to a class.

The methods the category adds become part of the class type. For example, methods added to the NSArray class in a category are among the methods the compiler expects an NSArray instance to have in its repertoire. Methods added to the NSArray class in a subclass are not included in the NSArray type. (This matters only for statically typed objects, since static typing is the only way the compiler can know an object’s class.)

Category methods can do anything that methods defined in the class proper can do. At runtime, there’s no difference. The methods the category adds to the class are inherited by all the class’s subclasses, just like other methods.

The declaration of a category interface looks very much like a class interface declaration—except the category name is listed within parentheses after the class name and the superclass isn’t mentioned. Unless its methods don’t access any instance variables of the class, the category must import the interface file for the class it extends:

#import "ClassName.h"
 
@interface ClassName ( CategoryName )
// method declarations
@end

The implementation, as usual, imports its own interface. A common naming convention is that the base file name of the category is the name of the class the category extends followed by “+” followed by the name of the category. A category implementation (in a file named ClassName+CategoryName.m) might therefore look like this:

#import "ClassName+CategoryName.h"
 
@implementation ClassName ( CategoryName )
// method definitions
@end

Note that a category can’t declare additional instance variables for the class; it includes only methods. However, all instance variables within the scope of the class are also within the scope of the category. That includes all instance variables declared by the class, even ones declared @private.

There’s no limit to the number of categories that you can add to a class, but each category name must be different, and each should declare and define a different set of methods.

 

How you Use Categories

You can use categories to extend classes defined by other implementors—for example, you can add methods to the classes defined in the Cocoa frameworks. The added methods are inherited by subclasses and are indistinguishable at runtime from the original methods of the class.

A category can be an alternative to a subclass. Rather than define a subclass to extend an existing class, through a category you can add methods to the class directly. For example, you could add categories to NSArray and other Cocoa classes. As in the case of a subclass, you don’t need source code for the class you’re extending.

The methods added in a category can be used to extend the functionality of the class or override methods the class inherits. A category can also override methods declared in the class interface. However, it cannot reliably override methods declared in another category of the same class. A category is not a substitute for a subclass. It’s best if categories don’t attempt to redefine methods that are explicitly declared in the class’s @interface section. Also note that a class can’t define the same method more than once.

When a category overrides an inherited method, the new version can, as usual, incorporate the inherited version through a message to super. But there’s no way for a category method to incorporate a method with the same name defined for the same class.

You can also use categories to distribute the implementation of a new class into separate source files—for example, you could group the methods of a large class into several categories and put each category in a different file. When used like this, categories can benefit the development process in a number of ways:

Categories are also used to declare informal protocols (see “Informal Protocols ”), as discussed under “Declaring Interfaces for Others to Implement.”

 

Categories of the Root Class

A category can add methods to any class, including the root class. Methods added to NSObject become available to all classes that are linked to your code. While this can be useful at times, it can also be quite dangerous. Although it may seem that the modifications the category makes are well understood and of limited impact, inheritance gives them a wide scope. You may be making unintended changes to unseen classes; you may not know all the consequences of what you’re doing. Moreover, others who are unaware of your changes won’t understand what they’re doing.

In addition, there are two other considerations to keep in mind when implementing methods for the root class:

  • Messages to super are invalid (there is no superclass).

  • Class objects can perform instance methods defined in the root class.

Normally, class objects can perform only class methods. But instance methods defined in the root class are a special case. They define an interface to the runtime system that all objects inherit. Class objects are full-fledged objects and need to share the same interface.

This feature means that you need to take into account the possibility that an instance method you define in a category of the NSObject class might be performed not only by instances but by class objects as well. For example, within the body of the method, self might mean a class object as well as an instance. See the NSObject class specification in the Foundation framework reference for more information on class access to root instance methods.

 

Extensions

Class extensions are like “anonymous” categories, except that the methods they declare must be implemented in the the main @implementation block for the corresponding class.

It is common for a class to have a publicly declared API and to then have additional API declared privately for use solely by the class or the framework within which the class resides. You can declare such API in a category (or in more than one category) in a private header file or implementation file as described above. This works, but the compiler cannot verify that all declared methods are implemented.

For example, the compiler will compile without error the following declarations and implementation:

@interface MyObject : NSObject
{
    NSNumber *number;
}
- (NSNumber *)number;
@end
 
@interface MyObject (Setter)
- (void)setNumber:(NSNumber *)newNumber;
@end
 
 
@implementation MyObject
 
- (NSNumber *)number
{
    return number;
}
@end

Note that there is no implementation of the setNumber method. If it is invoked at runtime, this will generate an error.

Class extensions allow you to declare additional required API for a class in locations other than within the primary class @interface block, as illustrated in the following example:

@interface MyObject : NSObject
{
    NSNumber *number;
}
- (NSNumber *)number;
@end
 
@interface MyObject ()
- (void)setNumber:(NSNumber *)newNumber;
@end
 
 
@implementation MyObject
 
- (NSNumber *)number
{
    return number;
}
- (void)setNumber(NSNumber *)newNumber
{
    number = newNumber;
}
@end

Notice that in this case:

  • No name is given in the parentheses in the second @interface block;

  • The implementation of the setNumber method appears within the main @implementation block for the class.

The implementation of the setNumber method must appear within the main @implementation block for the class (you cannot implement it in a category). If this is not the case, the compiler will emit a warning that it cannot find a method definition for setNumber.

fuente:  http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html

 

)( parentesys.es )( La cultura al alcance de todos )

Categories and Extensions
Fecha de publicación: 2007-11-14 02:11:47, por admin   (visto: 1291 veces)   (a 6 personas les ha parecido interesante)
Fuente:

Fotos de este contenido: si quieres añadir fotos, pulsa el botón Fotos

    
    


© parentesys.es - Todos los Derechos Reservados

Categories and Extensions

Comparte este contenido con todos tus amigos.



 Portada  :: Sección Informática

   Informática en Google  :: Buscador de Informática      Creación de páginas web de Informática

Opiniones sobre el artículo

Las opiniones que aquí se escriban deben hacer un uso cívico y respetuoso de la libertad de expresión. El administrador de parentesys.es se reserva el derecho de eliminar aquellos comentarios que no lo cumplan, o que no aporten información útil sobre el contenido arriba publicado.


 No hay opiniones. Sé el primero en escribir sobre este artículo.

Escribe tu comentario

Tu nombre: [obligatorio]

Título: [obligatorio]

Tu sitio web: (escríbelo con http://) [opcional]

Tu email: (lo mantendremos privado) [obligatorio]

Contenido: [obligatorio]

Código de seguridad anti-spam:*