Блоки против частных методов?

Каковы недостатки использования блока для определения частного метода внутри метода вместо использования реального частного метода? Есть ли что-то помимо того, что вы не можете вызвать метод из другого места?Блоки против частных методов?

Пример:

-(NSDictionary*)serialize 
{ 
    NSMutableDictionary* serialization = [NSMutableDictionary dictionary]; 

    TwoArgumentsBlockType serializeItemBlock = ^void(MyItemClass* item, NSString* identifier) 
    {  
     if (item) 
     { 
      // serialization code 
     } 
    }; 

    serializeItemBlock(self.someItem1, kSomeIdentifier1); 
    serializeItemBlock(self.someItem2, kSomeIdentifier2); 
    serializeItemBlock(self.someItem3, kSomeIdentifier3); 
    serializeItemBlock(self.someItem4, kSomeIdentifier4); 
    serializeItemBlock(self.someItem5, kSomeIdentifier5); 
    serializeItemBlock(self.someItem6, kSomeIdentifier6); 
    serializeItemBlock(self.someItem7, kSomeIdentifier7); 
    serializeItemBlock(self.someItem8, kSomeIdentifier8); 
    serializeItemBlock(self.someItem9, kSomeIdentifier9); 
    serializeItemBlock(self.someItem10, kSomeIdentifier10); 
    serializeItemBlock(self.someItem11, kSomeIdentifier11); 

    return serialization; 
}

источник

2012-06-11 diegoreymendez

это хороший вопрос, он заставил меня использовать мою eXpeRience с blocKs, чтобы думать по-другому. этот комментарий чувствителен к регистру;) P – Lio

Важность кода важна.

методы позволяют герметизировать целые участки кода друг от друга, и может сделать его легче читать ..

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

источник

2012-06-11 18:36:43

Я все еще не уверен в удобочитаемости. Вышеприведенный код имеет недостаток, заключающийся в том, что он длиннее, чем если бы этот метод был объявлен отдельно, но, с другой стороны, мне кажется, что это хороший способ предоставить метод scope - поскольку в то время он не предназначен для использования из других мест в коде. – diegoreymendez

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

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

источник

2012-06-11 18:35:42 terriblememory

Я думаю, что 3 большие недостатки:

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

Перемещение этого блока в метод разрешит все эти проблемы. Если блок используется некоторым API, который принимает обратный вызов блока в качестве аргумента, вы всегда можете указать return the block from a method.

источник

2012-06-12 16:34:24

Я считаю, что часть проблемы с моим первоначальным вопросом заключается в том, что ответ на это: «это зависит от того, что вам нужно». Например: часть того, что делает блоки интересными, заключается в том, что они позволяют разработчикам писать встроенные методы, где это действительно имеет смысл - например, в тех местах, где вам нужно выполнить код, который действительно не принадлежит нигде, и в тех местах, где читаемость если вы используете внешний метод. – diegoreymendez

ответ

Смежные вопросы