Каковы опасности метода Swizzling в Objective C?

я думаю, что это действительно отличный вопрос, и жаль, что вместо решения реального вопроса большинство ответов обошли проблему и просто сказали не использовать swizzling.

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

группирующее метод может быть использован для написания более эффективный, более обслуживаемый код. Он также может быть злоупотреблен и привести к ужасным ошибкам.

фон

как и все шаблоны проектирования, если мы полностью осознаем последствия шаблона, мы можем принимать более обоснованные решения о том, использовать его или нет. Синглеты-хороший пример того, что довольно спорно, и по уважительной причине - их действительно трудно реализовать должным образом. Однако многие люди по-прежнему предпочитают использовать синглеты. То же самое может можно сказать, о выпивке. Вы должны сформировать свое собственное мнение, как только полностью поймете как хорошее, так и плохое.

Обсуждение

вот некоторые из ловушек метода swizzling:

• метод swizzling не является атомарным
• изменяет поведение собственного кода
• возможные конфликты имен
• Swizzling изменяет аргументы метода
• порядок swizzles дела
• трудно понять (выглядит рекурсивный)
• трудно отлаживать

все эти моменты справедливы, и при их решении мы можем улучшить как наше понимание метода swizzling, так и методологию, используемую для достижения результата. Я возьму по одному.

метод swizzling не является атомарным

мне еще предстоит увидеть реализацию метода swizzling, который безопасен в использовании одновременно¹. На самом деле это не проблема в 95% случаев, когда вы хотите использовать метод swizzling. Обычно вы просто хотите заменить реализацию метода, и вы хотите, чтобы эта реализация использовалась в течение всего срока службы вашей программы. Это означает, что вы должны сделать свой метод swizzling в +(void)load. The load метод класса выполняется последовательно в начале вашего приложения. У вас не будет никаких проблем с параллелизмом, если вы сделаете свое swizzling здесь. Если вы должны были выпить в +(void)initialize, однако, вы можете закончить с условием гонки в вашей реализации swizzling, и среда выполнения может оказаться в странном состоянии.

изменяет поведение собственного кода

это проблема с swizzling, но это своего рода весь смысл. Цель состоит в том, чтобы иметь возможность изменить этот код. Причина, по которой люди указывают на это как на большое дело, заключается в том, что вы не просто меняете вещи для одного экземпляра NSButton что вы хотите все изменить, но вместо всех NSButton экземпляры в вашем приложении. По этой причине, вы должны быть осторожны, когда вы swizzle, но вам не нужно избегать его полностью.

подумайте об этом таким образом... если переопределить метод в классе и не вызвать метод суперкласса, могут возникнуть проблемы. В большинстве случаев суперкласс ожидает, что этот метод будет вызван (если не задокументировано иначе). Если вы примените эту же мысль к swizzling, вы покрыли большинство вопросов. Всегда называйте оригинальную реализацию. Если вы этого не сделаете, вы, вероятно, слишком сильно изменитесь, чтобы быть в безопасности.

возможные конфликты имен

конфликты имен являются проблемой во всем какао. Мы часто префиксные имена классов и имена методов в категориях. К сожалению, конфликты имен-это чума нашего языка. Но в случае со спиртным они не должны быть такими. Нам просто нужно немного изменить то, как мы думаем о методе swizzling. Наиболее swizzling делается так:

@interface NSView : NSObject
- (void)setFrame:(NSRect)frame;
@end

@implementation NSView (MyViewAdditions)

- (void)my_setFrame:(NSRect)frame {
    // do custom work
    [self my_setFrame:frame];
}

+ (void)load {
    [self swizzle:@selector(setFrame:) with:@selector(my_setFrame:)];
}

@end

это работает просто отлично, но что будет, если my_setFrame: было определено где-то еще? Эта проблема не уникальна для swizzling, но мы можем обойти ее в любом случае. Обходной путь имеет дополнительное преимущество решения других подводных камней, а также. Вот что мы делаем вместо этого:

@implementation NSView (MyViewAdditions)

static void MySetFrame(id self, SEL _cmd, NSRect frame);
static void (*SetFrameIMP)(id self, SEL _cmd, NSRect frame);

static void MySetFrame(id self, SEL _cmd, NSRect frame) {
    // do custom work
    SetFrameIMP(self, _cmd, frame);
}

+ (void)load {
    [self swizzle:@selector(setFrame:) with:(IMP)MySetFrame store:(IMP *)&SetFrameIMP];
}

@end

хотя это немного меньше похоже на Objective-C (поскольку он использует указатели функций), это позволяет избежать конфликтов именования. В принципе, это делает то же самое, что и обычное пойло. Это может немного измениться для людей, которые используют swizzling, как это было определено некоторое время, но в конце концов, я думаю, что это лучше. Метод swizzling определяется таким образом:

typedef IMP *IMPPointer;

BOOL class_swizzleMethodAndStore(Class class, SEL original, IMP replacement, IMPPointer store) {
    IMP imp = NULL;
    Method method = class_getInstanceMethod(class, original);
    if (method) {
        const char *type = method_getTypeEncoding(method);
        imp = class_replaceMethod(class, original, replacement, type);
        if (!imp) {
            imp = method_getImplementation(method);
        }
    }
    if (imp && store) { *store = imp; }
    return (imp != NULL);
}

@implementation NSObject (FRRuntimeAdditions)
+ (BOOL)swizzle:(SEL)original with:(IMP)replacement store:(IMPPointer)store {
    return class_swizzleMethodAndStore(self, original, replacement, store);
}
@end

Swizzling путем переименования методов изменяет аргументы метода

это большой в моем уме. Именно по этой причине стандартный метод swizzling не должен выполняться. Вы меняете аргументы к оригиналу реализация метода. Вот где это происходит:

[self my_setFrame:frame];

что делает эта строка:

objc_msgSend(self, @selector(my_setFrame:), frame);

который будет использовать среду выполнения для поиска реализации my_setFrame:. После реализации он вызывает реализацию с теми же аргументами, которые были приведены. Реализации он находит оригинальное воплощение setFrame:, поэтому он идет вперед и называет это, но