2012-06-11 44 views
6

Những nhược điểm của việc sử dụng một khối để xác định một phương thức riêng trong một phương thức, thay vì sử dụng một phương thức riêng tư thực sự là gì? Có cách nào khác ngoài việc không thể gọi phương thức từ một nơi khác không?Khối so với phương pháp riêng tư?

Ví dụ:

-(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; 
} 
+0

đây là một câu hỏi hay, nó làm tôi sử dụng eXpeRience của tôi với blocKs để suy nghĩ khác biệt. nhận xét này phân biệt chữ hoa chữ thường;) P – Lio

Trả lời

1

Độ rõ của mã là quan trọng.

Phương pháp cho phép bạn đóng gói toàn bộ các phần của mã xa nhau, và có thể làm cho nó dễ dàng hơn để đọc ..

Một lý do để lựa chọn phương pháp tư nhân trong khối là quản lý bộ nhớ. Đây là một chủ đề lớn để thảo luận ở đây, nhưng sufficed để nói rằng khối là lạ trong quản lý bộ nhớ, và không hành động như bất kỳ cấu trúc mã khác trong vấn đề đó.

+0

Tôi vẫn không chắc chắn về khả năng đọc. Đoạn mã trên có nhược điểm là dài hơn nếu phương pháp này được khai báo riêng, nhưng mặt khác, dường như tôi là một cách tốt để đưa ra phương thức một phạm vi - vì lúc đó nó không được sử dụng từ các vị trí khác trong mã. – diegoreymendez

+0

Trong mọi trường hợp, tôi hiểu điều này có lẽ là lý do quan trọng nhất tại sao người ta quyết định tránh phương pháp này. Cảm ơn câu trả lời. – diegoreymendez

1

Có thể cho rằng đó là khó khăn hơn để di chuyển mã - bạn có xu hướng có điểm vào chôn chứ không phải obscurely ở giữa một số chức năng, và không có tên hàm bạn có thể nhìn thấy trong trình gỡ lỗi hoặc tìm kiếm cho, có thể làm cho gỡ lỗi và truy tìm một chút khó khăn hơn.

6

Tôi nghĩ rằng 3 nhược điểm lớn nhất là:

  1. Khối là không thể tái sử dụng, như bạn đề cập.
  2. Khối không thể kiểm tra - bạn không thể viết một bài kiểm tra đơn vị xác minh khối thực hiện những gì bạn nghĩ.
  3. Mã không thể đọc được. Khi bạn đọc phương pháp này, điều quan trọng là một loạt các thứ được sắp xếp theo thứ tự, chứ không phải chi tiết về cách thực hiện tuần tự hóa.

Di chuyển khối này thành một phương pháp sẽ giải quyết tất cả các vấn đề này. Nếu khối này được sử dụng bởi một số API có tính năng gọi lại chặn làm đối số, bạn luôn có thể return the block from a method.

+0

Tôi tin rằng một phần của vấn đề với câu hỏi ban đầu của tôi là câu trả lời cho nó là: "nó phụ thuộc vào những gì bạn cần". Ví dụ: một phần làm cho các nhà phát triển viết các phương thức nội tuyến mà nó thực sự có ý nghĩa - ví dụ ở những nơi bạn cần thực thi mã thực sự không thuộc bất kỳ nơi nào khác và ở những nơi dễ đọc đau khổ nếu bạn sử dụng một phương pháp bên ngoài. – diegoreymendez

Các vấn đề liên quan