2010-03-27 7 views
1

J'ai les extraits de protocole de code suivants:iPhone: protocole de partage/code de délégué

@protocol FooDelegate;

@interface Foo: UIViewController { id délégué; } ...

@protocol FooDelegate ... // Méthode 1 ... // Méthode 2 ... @end

En outre, le code suivant qui met en œuvre FooDelegate:

@interface bar1: UIViewController {...}

@interface bar2: UITableViewController {...}

Il s'avère que l'implémentation de FooDelegate est la même sur les deux classes Bar1 et Bar2. Je copie actuellement juste le code d'exécution de FooDelegate de Bar1 à Bar2.

Comment est-ce que je structure/implémente de telle manière que Bar1 et Bar2 partagent le même code dans une base de code unique (pas comme actuellement avec 2 copies) puisqu'ils sont les mêmes?

Merci d'avance pour votre aide.

+0

avez-vous résolu votre problème?Je suis confronté à la même chose et je ne suis pas satisfait de la réponse que j'ai reçue jusqu'à présent :( – amok

Répondre

0

Faire un nouvel objet, MyFooDelegate:

@interface MyFooDelegate : NSObject <FooDelegate> 

Ensuite Bar1 et Bar2 peuvent chacun créer une instance de celui-ci (ou partager une instance). Dans ces classes, vous pouvez éliminer les méthodes de délégués et ajouter des lignes comme:

MyFooDelegate *myDooDelegateInstance = ...; 

foo.delegate = myFooDelegateInstance; 

Vous pouvez également créer une instance de MyFooDelegate dans un fichier NIB et connecter les prises de délégué du contrôleur de vue à lui, si on le souhaite.

De cette façon, vous n'aurez pas de code dupliqué dans vos fichiers source ou dans vos exécutables.

+0

Je ne pense pas que cela résout vraiment le problème beaucoup.Bar1 et Bar2 ont encore besoin d'ajouter du code dans tous les mêmes endroits Pour se connecter à leur instance MyFooDelegate, la vraie solution serait une forme de mixins, que Cocoa n'a pas vraiment dans ce cas –

+1

Si le problème est d'avoir le même code dans deux fichiers source, cela résout absolument le problème – benzado

+1

Non, il échange un problème pour un autre parce que maintenant vous avez juste un type différent de code source qui est le même dans deux fichiers source: –

1

Option A: Mettre en œuvre la méthode dans une catégorie

Toutes les propriétés utilisées doivent être déclarées dans UIViewController.

UITableViewController est une sous-classe de UIViewController.

//UIViewController+MyAdditions.h 
@interface UIViewController (MyAdditions) 
- (void)myCommonMethod; 
@end 

//UIViewController+MyAdditions.m 

@implementation UIViewController (MyAddtions) 
- (void)myCommonMethod { 
// insert code here 
} 

La nouvelle méthode ajouté à UIViewController sera héritée par Bar1 et Bar2

Option B: Créer une classe MyViewControllerHelper

Si vous pouvez, mettre en œuvre votre code commun en tant que méthode de classe, sinon vous devrez créer une instance de votre classe d'assistance soit temporairement, soit en tant que propriété de Bar1 et Bar2

@interface MyViewControllerHelper : NSObject 
- (void)myCommonMethod; 
@end 

@implementation MyViewControllerHelper 
- (void)myCommonMethod { 
    // common code here 
} 

@interface Bar1 : UIViewController { 
MyViewControllerHelper *helper; 
} 
@property MyViewControllerHelper *helper; 
@end 

@implementation Bar1 
@synthesize helper; 
- (void)someMethod { 
    [helper myCommonMethod]; 
} 
@end 

@interface Bar2 : UITableViewController { 
MyViewControllerHelper *helper; 
} 
@property MyViewControllerHelper; 
@end 

@implementation Bar2 
@synthesize helper; 
- (void)someOtherMethod { 
    [helper myCommonMethod]; 
} 
@end 
+0

L'option A comporte un risque inutile, puisque vous allez ajouter des méthodes déléguées à la classe UIViewController du système. Si le protocole délégué est entièrement personnalisé, il est probablement sûr, mais s'il s'agit d'un protocole fourni par le système (par exemple, UIActionSheetDelegate), vous pouvez théoriquement rompre des éléments indépendants (par exemple, le contrôleur de vue du sélecteur de photos système). – benzado

+0

C'est toujours une question de choix. L'option A évite entièrement la délégation qui, selon moi, pourrait causer des problèmes car UIViewController n'implémente pas un protocole délégué mais UITableViewController le fait. Les exemples Foo et Bar ne fournissent pas suffisamment de contexte pour déterminer s'il s'agit de méthodes utilitaires * manquantes * dans l'API (pensez au codage base64 des chaînes). Tout risque doit être pesé contre la violation du principe * dry * et la complexité de la gestion d'une catégorie ou d'un couplage entre un contrôleur et de nouveaux objets auxiliaires. – falconcreek

Questions connexes