Vous faites mal! Une brève discussion sur les catégories et la Voie de cacao

Parlons un élément du langage Objective-C qui est assez unique: Catégories. Eh bien, pas tout à fait unique: la dernière édition de C # a ajouté quelque chose qui s'appelle Méthodes d'extension, Qui est très similaire, mais il n'a pas été assez longtemps pour avoir vraiment sombré dans la psyché collective des développeurs. NET encore. Autre que cette addition récente à C # et le langage obscur TOM, Je ne connais pas personnellement de tout les langages de programmation qui ont un équivalent à l'Objective-C les catégories. Il ya probablement une certaine flottante là-bas, mais le "biggie" langues dans le monde de la programmation orientée objet - Java, Ruby, Python, C + + - n'ont pas une construction équivalente.

Les catégories sont «uber-cool, et presque universellement sous-utilisés par les programmeurs de nouvelles Objective-C. Bien que je ne suis pas un grand fan de C # ou. Net, je dois donner bravo Microsoft pour reconnaître awesomeness et en l'incorporant. Gardons nos doigts franchi qu'ils l'utilisent aussi efficacement que les ingénieurs de NeXT et Apple ont en Cocoa.

Un grand nombre de gens qui viennent de cacao à partir d'autres langues et lu Apple ouvrage de référence sur Objective-C survoler la section sur les catégories, dites «cool», et de passer ensuite. Heck, Apple propres Objective-C apprêt ne fait aucune mention des catégories, ce qui est juste une honte, parce que les programmeurs Cocoa utilisent des catégories beaucoup. Alors, quels sont-ils, vous demandez-vous?

Autrement dit, les catégories vous permettent d'ajouter des méthodes à des classes existantes sans les sous-classes. Vous ne pouvez pas ajouter des variables d'instance (familièrement appelé «ivars" ou "Ivars" dans le monde de cacao) ou des propriétés, mais vous pouvez ajouter les deux méthodes de classe et d'instance en toute impunité.

Alors pourquoi est-ce cool? Prenons un exemple, et regardez les choix de conception qui s'offrent à nous en Objective-C par rapport aux autres langues. Je vais utiliser un exemple du monde réel, mais très simple ici, mais il ya d'innombrables exemples dans les jours à jour d'un programmeur de vie où les catégories peuvent rendre votre base de code globale plus élégante, dont beaucoup sont plus complexes et plus convaincante que cela une.

Un de mes projets parallèles actuelle est la construction de deux à base de cacao clients NNTP (pour accéder à Usenet): un pour le Mac et l'autre pour l'iPhone. Maintenant, les serveurs NNTP attend des informations à jour pour être passé dans l'une manière très spécifique - dans le format spécifié dans RFC 822. Une chaîne de date pour NNTP doit ressembler à ceci:

08 Apr 2008 12:14:40 -0500

Formatage des dates avec Objective-C/Cocoa est relativement facile, donc je peux créer une chaîne dans ce format à partir d'un NSDate objet relativement facilement, en faisant cela:

NSString *dateString = [theDate descriptionWithCalendarFormat:@"%d %b %Y %H:%M:%S %z" timezone:nil locale:nil];

Mais d'où vient ce code aller? Dois-je vraiment envie de mettre ce code partout où je besoin de l'utiliser? Eh bien, peut-être ... comme j'ai dit, c'est un exemple simple à des fins d'illustration, et pas aussi convaincante que de nombreux autres exemples du monde réel, mais jouer avec moi ici, ok?

Dans un client NNTP, cette même ligne de code à long aurait probablement besoin d'être mis en dizaines ou même centaines d'endroits. Mais que faire si RFC822 venaient à changer? Ou si, après avoir utilisé un code similaire dans des dizaines de lieux, je me rends compte que j'ai fait une erreur? Quelle douleur!

Il ya plusieurs façons de traiter ce problème dans d'autres langues. Je pouvais, par exemple, créer un private static méthode ou une fonction (selon la langue) qui prend une date et retourne une chaîne formatée correctement. En C ou une de ses sur-ensembles, je pouvais choisir de créer une macro préprocesseur utilisant #define pour éviter d'avoir la même logique en plusieurs endroits. Je pourrais aussi choisir de sous-classe NSDate et d'ajouter une méthode dans la sous-classe de revenir à cette méthode. Dans certains cas, qui pourraient être appropriées, mais dans une strongly-typed langage comme le C + + ou Java, je ne voulez probablement pas le faire juste pour obtenir une seule méthode, car elle obligerait un grand nombre de coercition de type et le désordre dans mon code.

Sans catégories, dérivation pourrait être un bon choix en Objective-C, car il est weakly-typed et pourrait être fait avec désordre minime. Mais nous pouvons le faire sans merci désordre à des catégories. En Objective-C, je peux simplement ajouter une méthode à l'existant NSDate classe pour faire ce dont j'ai besoin. Partout j'ai besoin d'utiliser cette nouvelle méthode, je viens de vous assurer d'inclure le fichier en-tête de ma catégorie. Dans mon exemple simple, le fichier d'entête catégorie (.h) Devrait ressembler à ceci:

#import cocoa/cocoa.h
#import appkit/appkit.h
@interface NSDate(NNTP)

-(NSString *)rfc822DateString;
@end

et ma mise en œuvre (.m) Fichier devrait ressembler à ceci:

#import "NSDate-NNTP.h"

@implementation NSDate(NNTP)
-(NSString *)rfc822DateString
{
return [self  descriptionWithCalendarFormat:@"%d %b %Y %H:%M:%S %z" timeZone:nil locale:nil];
}
@end

Une fois que j'ai ce, n'importe où j'ai besoin d'une date formatée de cette façon, j'ai tout simplement appeler cette nouvelle méthode à droite sur l'objet date, comme ceci:

NSString *dateString = [myDate rfc822DateString];

Le résultat? Très lisible et le code beaucoup plus courte, et il place la logique réelle dans un seul et même endroit le rendant facile à entretenir.

Si vous voulez voir une utilisation plus complexe de l'Objective-C les catégories, consultez cette ce blog tôt affichage où j'ai montré comment ajouter le support des sockets réseau à la livraison NSFileHandle class.

Catégories rendre plus facile à coller avec le prépondérante philosophie de conception utilisé tout au long de cacao, et sa présence permet à la trousse de demande et la trousse interface d'avoir des hiérarchies de classes beaucoup moins profond que ce que vous trouverez dans d'autres boîtes à outils d'application orienté objet. Si vous travaillez en Cocoa / Objective-C, vous avez vraiment, vraiment devraient prendre l'habitude d'utiliser des catégories quand il fait sens. Quand est-il du sens? Chaque fois que vous vous dites, "Gee, je souhaite la classe livrée [X] a une méthode qui ne [Y]».