Придушити попередження "Категорія реалізує метод, який також буде реалізований своїм основним класом"

Мені було цікаво, як придушити попередження:

Категорія реалізує метод, який також буде реалізований його основним класом.

Я маю це для конкретної категорії коду:

+ (UIFont *)systemFontOfSize:(CGFloat)fontSize {
    return [self aCustomFontOfSize:fontSize];
}

Категорія дозволяє додавати нові методи до наявного класу. Якщо ви хочете повторно реалізувати метод, який вже існує в класі, ти зазвичай створюєш підклас замість категорії.

Документація Apple: Налаштування існуючих класів

Якщо назва методу, оголошеного в категорії, збігається з методом в початковому класі або методом в іншій категорії того ж класу (або навіть суперкласу), поведінка не визначена щодо того, який спосіб використання використовується в час виконання.

Два методи з точно таким же підписом у тому ж класі призвели б до непередбачуваної поведінки, оскільки кожен абонент не може вказати, яку реалізацію вони хочуть.

Отже, вам слід або використовувати категорію та надати назви методів, які є новими та унікальними для класу, або підклас, якщо ви хочете змінити поведінку існуючого методу в класі.

Незважаючи на те, що все, що було сказано, є правильним, воно насправді не відповідає на ваше запитання, як придушити попередження.

Якщо вам доведеться мати цей код з якихось причин (у моєму випадку я маю HockeyKit у своєму проекті, і вони замінюють метод у категорії UIImage [редагувати: це вже не так]), і вам потрібно змусити ваш проект скласти , ви можете використовувати #pragmaоператори, щоб заблокувати попередження так:

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-protocol-method-implementation"

// do your override

#pragma clang diagnostic pop

Інформацію я знайшов тут: http://www.cocoabuilder.com/archive/xcode/313767-disable-warning-for-override-in-category.html

Кращою альтернативою (див. Відповідь bneely на те, чому це попередження рятує вас від катастрофи), - це використовувати метод swizzling. Скориставшись методом swizzling, ви можете замінити існуючий метод із категорії без невизначеності того, хто «перемагає», і при цьому зберігає можливість передзвонити до старого методу. Секрет полягає в тому, щоб надати переопределенню інше ім'я методу, а потім поміняти їх за допомогою функцій виконання.

#import <objc/runtime.h> 
#import <objc/message.h>

void MethodSwizzle(Class c, SEL orig, SEL new) {
    Method origMethod = class_getInstanceMethod(c, orig);
    Method newMethod = class_getInstanceMethod(c, new);
    if(class_addMethod(c, orig, method_getImplementation(newMethod), method_getTypeEncoding(newMethod)))
        class_replaceMethod(c, new, method_getImplementation(origMethod), method_getTypeEncoding(origMethod));
    else
    method_exchangeImplementations(origMethod, newMethod);
}

Потім визначте власну реалізацію:

+ (UIFont *)mySystemFontOfSize:(CGFloat)fontSize {
...
}

Замініть реалізацію за замовчуванням на вашу:

MethodSwizzle([UIFont class], @selector(systemFontOfSize:), @selector(mySystemFontOfSize:));

Спробуйте це у своєму коді:

+(void)load{
    EXCHANGE_METHOD(Method1, Method1Impl);
}

UPDATE2: Додайте цей макрос

#import <Foundation/Foundation.h>
#define EXCHANGE_METHOD(a,b) [[self class]exchangeMethod:@selector(a) withNewMethod:@selector(b)]

@interface NSObject (MethodExchange)
+(void)exchangeMethod:(SEL)origSel withNewMethod:(SEL)newSel;
@end

#import <objc/runtime.h>

@implementation NSObject (MethodExchange)

+(void)exchangeMethod:(SEL)origSel withNewMethod:(SEL)newSel{
    Class class = [self class];

    Method origMethod = class_getInstanceMethod(class, origSel);
    if (!origMethod){
        origMethod = class_getClassMethod(class, origSel);
    }
    if (!origMethod)
        @throw [NSException exceptionWithName:@"Original method not found" reason:nil userInfo:nil];
    Method newMethod = class_getInstanceMethod(class, newSel);
    if (!newMethod){
        newMethod = class_getClassMethod(class, newSel);
    }
    if (!newMethod)
        @throw [NSException exceptionWithName:@"New method not found" reason:nil userInfo:nil];
    if (origMethod==newMethod)
        @throw [NSException exceptionWithName:@"Methods are the same" reason:nil userInfo:nil];
    method_exchangeImplementations(origMethod, newMethod);
}

@end

Для придушення цього попередження компілятора ви можете скористатися методом шипучих перешкод. Ось як я реалізував метод шипування для малювання полів у UITextField, коли ми використовуємо спеціальний фон з UITextBorderStyleNone:

#import <UIKit/UIKit.h>

@interface UITextField (UITextFieldCatagory)

+(void)load;
- (CGRect)textRectForBoundsCustom:(CGRect)bounds;
- (CGRect)editingRectForBoundsCustom:(CGRect)bounds;
@end

#import "UITextField+UITextFieldCatagory.h"
#import <objc/objc-runtime.h>

@implementation UITextField (UITextFieldCatagory)

+(void)load
{
    Method textRectForBounds = class_getInstanceMethod(self, @selector(textRectForBounds:));
    Method textRectForBoundsCustom = class_getInstanceMethod(self, @selector(textRectForBoundsCustom:));

    Method editingRectForBounds = class_getInstanceMethod(self, @selector(editingRectForBounds:));
    Method editingRectForBoundsCustom = class_getInstanceMethod(self, @selector(editingRectForBoundsCustom:));


    method_exchangeImplementations(textRectForBounds, textRectForBoundsCustom);
    method_exchangeImplementations(editingRectForBounds, editingRectForBoundsCustom);

}


- (CGRect)textRectForBoundsCustom:(CGRect)bounds
{
    CGRect inset = CGRectMake(bounds.origin.x + 10, bounds.origin.y, bounds.size.width - 10, bounds.size.height);
    return inset;
}

- (CGRect)editingRectForBoundsCustom:(CGRect)bounds
{
    CGRect inset = CGRectMake(bounds.origin.x + 10, bounds.origin.y, bounds.size.width - 10, bounds.size.height);
    return inset;
}

@end

Властивості перевищення верхової їзди дійсні для розширення класу (анонімна категорія), але не для звичайної категорії.

Згідно з документами Apple Docs, використовуючи розширення класу (Anonymous Category), ви можете створити приватний інтерфейс для загальнодоступного класу, таким чином, щоб приватний інтерфейс міг змінити загальнодоступні властивості. тобто ви можете змінити властивість з readonly на readwrite.

Випадком для цього є коли ви пишете бібліотеки, які обмежують доступ до загальнодоступних властивостей, тоді як для цього ж властивості потрібен повний доступ для запису зчитування в бібліотеці.

Посилання Apple Docs: https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/CustomizingExistingClasses/CustomizingExistingClasses.html

Пошук " Використовувати розширення класів для приховування приватної інформації ".

Тож ця методика дійсна для розширення класу, але не для категорії.

Категорії - це добре, але ними можна зловживати. При написанні категорій ви, як правило, НЕ повинні повторно застосовувати методи виходу. Це може спричинити дивні побічні ефекти, оскільки ви переписуєте код, який залежить від іншого класу. ви можете зламати відомий клас і перетворити налагоджувач всередину. Це просто погане програмування.

Якщо вам потрібно це, ви дійсно повинні підкласифікувати його.

Тоді пропозиція шиплячи, це для мене великий НІ-НІ-НІ.

Переміщення його під час виконання - це повна NO-NO-NO.

Хочете, щоб банан був схожий на апельсин, але лише під час виконання? Якщо ви хочете помаранчевий, то напишіть апельсин.

Не погляньте на банан і поводьтесь як апельсин. І ще гірше: не перетворюйте свій банан на секретний агент, який буде тихо саботувати банани у всьому світі на підтримку апельсинів.

Yikes!

У мене була ця проблема, коли я реалізував метод делегата в категорії, а не в основному класі (навіть не було реалізації основного класу). Для мене рішення було перенести з файлу заголовка основного класу в файл заголовка категорії. Це добре працює