티스토리 뷰

Objective-C 2.0

4. Protocols and Categories

varyeun 2022. 3. 4. 15:26

Item 23: Use Delegate and Data Source Protocols for Interobject Communication

 

@protocol EOCNetworkFetcherDelegate
- (void)networkFetcher:(EOCNetworkFetcher*)fetcher
        didReceiveData:(NSData*)data;
- (void)networkFetcher:(EOCNetworkFetcher*)fetcher
        didFailWithError:(NSError*)error;
@end

A delegate protocol is usually named as the class name followed by the word delegate, using camel casing for the whole name.

The protocol provides a property on the class that has the delegate. Therefore, the interface would look like this:

@interface EOCNetworkFetcher : NSObject
@property (nonatomic, weak)
    id <EOCNetworkFetcherDelegate> delegate;
@end

It’s important to make sure that the property is defined as weak and not strong, since it must be a nonowning relationship.

Ownership diagram showing delegate being nonretained in order to avoid retain cycle

 

Protocols can also be used to provide an interface through which the data that a class requires is obtained. This other use of the Delegate pattern is referred to as the Data Source pattern because its aim is to provide data to the class. The flow of information is toward the class; with a normal delegate, the flow of information is away from the class.

Flow of information is out of the class for a delegate and into the class for a data source.

 

Declaring it in the interface is useful if you want to advertise to others that you implement that protocol; however, in the case of delegates, it’s usual to care only about it internally. So it’s common to declare it in the class-continuation category like so:

@implementation EOCDataModel () <EOCNetworkFetcherDelegate>
@end

@implementation EOCDataModel
- (void)networkFetcher:(EOCNetworkFetcher*)fetcher
        didReceiveData:(NSData*)data {
    /* Handle data */
}
- (void)networkFetcher:(EOCNetworkFetcher*)fetcher
        didFailWithError:(NSError*)error {
    /* Handle error */
}
@end

 

If you create a structure that uses only 1-bit bitfields, you can pack in a lot of Booleans into a small amount of data.

@interface EOCNetworkFetcher () {
    struct {
        unsigned int didReceiveData      : 1;
        unsigned int didFailWithError    : 1;
        unsigned int didUpdateProgressTo : 1;
    } _delegateFlags;
}
@end

- (void)setDelegate:(id<EOCNetworkFetcher>)delegate {
    _delegate = delegate;
    _delegateFlags.didReceiveData =
      [delegate respondsToSelector:
                @selector(networkFetcher:didReceiveData:)];
    _delegateFlags.didFailWithError =
      [delegate respondsToSelector:
                @selector(networkFetcher:didFailWithError:)];
    _delegateFlags.didUpdateProgressTo =
      [delegate respondsToSelector:
                @selector(networkFetcher:didUpdateProgressTo:)];
}

// Set flag
_delegateFlags.didReceiveData = 1;

// Check flag
if (_delegateFlags.didReceiveData) {
    // Yes, flag set
}

 

 

Item 24: Use Categories to Break Class Implementations into Manageable Segments

 

Item 25: Always Prefix Category Names on Third-Party Classes

 

Item 26: Avoid Properties in Categories

 

Categories should be thought of as a way to extend functionality of the class, not the data that it encapsulates.

 

 

 

Item 27: Use the Class-Continuation Category to Hide Implementation Detail

 

// EOCClass.h
#import <Foundation/Foundation.h>

@interface EOCClass : NSObject
@end

// EOCClass.m
#import "EOCClass.h"
#import "EOCSuperSecretClass.h"

@interface EOCClass () {
    EOCSuperSecretClass *_secretInstance;
}
@end

@implementation EOCClass
// Methods here
@end

 

Finally, the class-continuation category is a good place to state that your object conforms to protocols that should be considered private. Often, you don’t want to leak information that you conform to a certain protocol in the public interface, maybe because the protocol is part of your private API.

 

 

Item 28: Use a Protocol to Provide Anonymous Objects

 

  


https://www.oreilly.com/library/view/effective-objective-c-20/9780133386950/

 

Effective Objective-C 2.0: 52 Specific Ways to Improve Your iOS and OS X Programs

Write Truly Great iOS and OS X Code with Objective-C 2.0! Effective Objective-C 2.0 will help you harness all of Objective-C’s expressive power to write OS X or iOS code … - Selection from Effective Objective-C 2.0: 52 Specific Ways to Improve Your iOS

www.oreilly.com

 

이 책으로 공부 중이고, 기억하면 좋을 것 같은 부분을 발췌 + 공부 + 정리합니다.

'Objective-C 2.0' 카테고리의 다른 글

6. Blocks and Grand Central Dispatch  (0) 2022.12.29
5. Memory Management  (0) 2022.05.10
3. Interface and API Design  (0) 2022.01.25
2. Objects, Messaging, and the Runtime  (0) 2022.01.19
1. Accustoming Yourself to Objective-C  (0) 2022.01.17
댓글