2

I have a proper delegate protocol created in Objective-C and I'm updating it. One of the updates requires a method be deprecated, but it is technically still valid for the time being.

Here is the original delegate method. Notice it's optional, so it's not an essential method, which kind of clouds my judgment about whether it should be kept functional at all.

@protocol MyDelegate <NSObject>

@optional
- (void)requestFailedWithError:(NSError *)error;

@end

It was used in the class plainly and simply in two places. Like so:

if ([self.delegate respondsToSelector:@selector(requestFailedWithError:)]) {
    [self.delegate requestFailedWithError:error];
}

Now I've updated. In the update it looked like a better option was to divide the function into unique error returns based on when the error occurs, because the uses of this method grew to more than two places and could have very different responses. This allows the consumer to ignore particular types of errors or at the very least handle each error differently without giant if statements. These are the new delegate methods:

@protocol MyDelegate <NSObject>

@optional
- (void)aRequestFailedWithError:(NSError *)error;
- (void)bRequestFailedWithError:(NSError *)error;

- (void)requestFailedWithError:(NSError *)error DEPRECATED_ATTRIBUTE;

@end

In the class I'm calling them as expected but I'm failing over to the deprecated method if the class hasn't implemented the newer method. Of course if they have neither method it does nothing.

if ([self.delegate respondsToSelector:@selector(aRequestFailedWithError:)]) {
    [self.delegate aRequestFailedWithError:error];
} else {
    if ([self.delegate respondsToSelector:@selector(requestFailedWithError:)]) {
        [self.delegate requestFailedWithError:error];
    }
}

It seemed like a good idea at the time, but am I just stringing along the method longer than needed by keeping it functional while deprecated? I feel like a deprecated method should be functional, just discouraged. Then when the time comes, just yank the whole method.

Does this seem like common practice, a good idea, etc.? All comments are welcome. Just looking for the best pattern when dealing with this type of API change.

jscs
  • 63,694
  • 13
  • 151
  • 195
Ryan Poolos
  • 18,421
  • 4
  • 65
  • 98
  • 1
    Depends on your audience. If you're writing an API that is used by other organizations then what you did is good (to a point). If it's just internal users, and eliminating the use of the method could be quickly fixed, then clean up now. A "middle of the road" approach is to note the presence of the method and emit (NSLog) a warning when it's seen, whether or not you do the dual mode thing. – Hot Licks Feb 19 '13 at 19:47
  • It is internal but projects are not updated often or by the same developer so there is a good chance when a project is opened it will be out of date which is why I chose to deprecate at all for an internal library. I'd rather it throw deprecated warnings than errors incase the project needs a hotfix. As far as "to a point" I plan on letting this ride until another change is made to the delegate. – Ryan Poolos Feb 19 '13 at 20:06

0 Answers0