使用清洗委托模式

Question

I have a protocol like this :

#import <Foundation/Foundation.h>

@protocol StoreDisplayerDelegate <NSObject>

-(void) changeActionForObjectWithId:(NSString *)objectID ;

@end

and i have a callass with conforms to the precedent protocol StoreDisplayerDelegate

@interface ShelfVC : UIViewController :<StoreDisplayerDelegate>
....

@implementation ShelfVC 
...

- (void)viewDidLoad {

   ...
   DownloadManager *manager = [DownloadManager sharedInstance];
   [manager setStoreDisplayerDelegate:self];
   ....
}

#pragma mark StoreDisplayerDelegate methods
-(void) changeActionForObjectWithId:(NSString *)objectID {
   ......
}

@end

And in my code ( in the same class) sometimes i am calling the delegate methods to do something form me, for example :

- (void)anOtherMethod{
   [self changeActionForObjectWithId:nil];
}

My Questions 1. is : When object is a delegate for an other object, is the methods implemented by the delegate called only by the other object ( witch have a reference for it ) ? i mean by this, for example in the code i have shown should the methode changeActionForObjectWithId: just called by the downLoad manager or can i use it in the inernal of my class like this :

1. is what i am doing cleaning or bad design of using Delegate pattern ?

I hope that it is clear.

Answer 1

Your delegate method name sounds like a command.

-(void)changeActionForObjectWithId:(NSString *)objectID;

It sounds like your StoreDisplayer is telling delegate to do something. The fact that you are also tempted to call that method from within the ViewController confirms it.

That is not the delegate pattern. The delegate pattern is for a class to inform a delegate of a change, or to ask the delegate for some information. The delegating class (StoreDisplayer?) shouldn't know about what any particular delegate does, so it shouldn't be able to give it direct specific commands. Only delegate generic behaviour to it.

Delegate method look more like these examples:

-(BOOL)actionShouldChangeForStoreDisplayer:(StoreDisplayer*)storeDisplayer;
-(void)actionWillChangeForStoreDisplayer:(StoreDisplayer*)storeDisplayer objectId:(NSString *)objectId;
-(void)actionDidChangeForStoreDisplayer:(StoreDisplayer*)storeDisplayer objectId:(NSString *)objectId;

I'm not saying those are what you need, but they should give you the idea.

When your delegate methods look like this, clearly you will not be tempted to call them from anything other than the class that's doing the delegation (StoreDisplayer).

Answer 2

In my project I have the same situation for different purpose. In my opinion the delegate method must be called only by the other object, because it is its method.

If you need to do certain action in the delegate method, its better to create another private method to performing the action and call it from the delegate methods.

Some example. Instead of doing this:

- (void)anOtherMethod {
   [self changeActionForObjectWithId:nil];
}

- (void)changeActionForObjectWithId:(NSString *)objectID {
   < some actions >
} 

I do this:

- (void)privateMethod{
   < some actions >
}

- (void)anOtherMethod {
   [self privateMethod];
}

- (void)changeActionForObjectWithId:(NSString *)objectID {
   [self privateMethod];
} 

Why do this? Because you have to think to the delegate methods to an "extension" to your base object: if you delete the "changeActionForObjectWithId" (becuase, for example, you don't need the delegate anymore after a refactoring) the code will continue to work.

Answer 3

A delegate is a protocol that allows an object to perform certain actions.

In your example:

@interface ShelfVC : UIViewController : <StoreDisplayerDelegate>

This tells the compiler that UIViewController is going to implement some methods in the StoreDisplayerDelegate protocol. How the object that applicable to the StoreDisplayerDelegate behave would depend on the protocol in the delegate methods.

Answer 4

You got a little confused with delegates and protocols. a delegate is a design-pattern wich uses a protocol. a protocol only defines methods and properties expected to be implemented by another (unspecific) class. from where this methods/properties get accessed doesn't matter.