6

What are the disadvantages of using a block to define a private method within a method, instead of using a real private method? Is there any apart from not being able to call the method from somewhere else?

Example:

-(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;
}
diegoreymendez
  • 1,997
  • 18
  • 20
  • this is a Nice question, it made me use my eXpeRience with blocKs to think differentLy. this comment is case sensitive ;) P – Lio Jun 16 '12 at 04:15

3 Answers3

6

I think the 3 biggest drawbacks are:

  1. The block isn't reusable, as you mention.
  2. The block isn't testable--you can't write a unit test that verifies the block does what you think it does.
  3. The code is less readable. When you're reading this method, what's important is that a series of things are serialized, not the details of how the serialization is implemented.

Moving this block into a method would resolve all of these issues. If the block is used by some API that takes a block callback as an argument, you can always return the block from a method.

Christopher Pickslay
  • 17,523
  • 6
  • 79
  • 92
  • I believe part of the problem with my initial question is that the answer to it is: "it depends on what you need". For example: part of what makes blocks so interesting is that they allow developers to write inline methods where it really makes sense - for example in places where you need to execute code that really doesn't belong anywhere else, and in places where readability would suffer if you used an external method. – diegoreymendez Jun 13 '12 at 12:54
1

Arguably it's harder to navigate the code - you tend to have entry points buried rather obscurely in the middle of some function, and there's no function name you can see in the debugger or search for, which can make debugging and tracing a little harder.

terriblememory
  • 1,712
  • 3
  • 18
  • 25
1

Clarity of the code is important.

Methods allow you to encapsulate entire sections of code apart from each other, and can make it easier to read..

Another reason to choose private methods over blocks is memory management. This is far to big of a topic to discuss here, but sufficed to say that blocks are weird in the memory management, and don't act like any other code structure in that regard.

Richard J. Ross III
  • 55,009
  • 24
  • 135
  • 201
  • I'm still unsure about readability. The code above has the disadvantage of being longer than it would be if the method was declared separately, but on the other hand it seems to me like a good way to give the method a scope - since at the time it's not meant to be used from other locations in the code. – diegoreymendez Jun 11 '12 at 19:18
  • In any case I understand this is probably the most important reason why one would decide to avoid this approach. Thanks for the answer. – diegoreymendez Jun 11 '12 at 19:28