한 완료 블록 대 두 완료 블록

Question

나는 twoBlock 방식을 사용하는 network kit을 사용하고 있지만 내 코드에는 oneBlock을 사용하는 것이 더 좋습니다. twoBlock 접근 방식이 더 좋으면 혼란 스럽습니다. 여하튼 나는 그것을 보지 않는다.

하나의 접근 방식이 다른 접근 방식보다 낫지는 않습니까? 처리에 전념

-(void)oneBlock { 
    [self startWithCompletionBlock:^(id obj, NSError* error) { 
     if(error) { 
      NSLog(@"error: %@", error); 
     } else { 
      NSLog(@"success: %@", obj); 
     } 
    }]; 
} 

---

twoBlock 방식

2 블록 : 데이터 에러를 결합

---

oneBlock 방식

1 블록 데이터 및 오류 :

-(void)twoBlocks { 
    [self startWithCompletionBlock:^(id obj) { 
     NSLog(@"success: %@", obj); 
    } errorBlock:^(NSError* error) { 
     NSLog(@"error: %@", error); 
    }]; 
} 

Answer 1

나는 당신이 어느 쪽이 더 좋다라고 말할 수 있다고 생각하지 않는다. 찬반 양론의 균형이 다릅니다.

두 블록 접근 방식의 가장 큰 장점은 "행복한"경로와 오류 관리 코드를 더 잘 구분할 수 있다는 것입니다. (이 분리는 예외를 사용함으로써 얻을 수있는 장점 중 하나와 비슷하지만 다른 짐승입니다. 실제로 catch 블록은 "기능적"블록 외부의 한 장소에서 수집을 허용합니다. "기능적"블록 내에서 발생할 수있는 오류 상황과 그 관리가 정상적으로 분산되어있을 수있는 오류 조건이 여러 개 있습니다. 위의 2 블록 예에서는 오류 조건을 관리하는 코드가 여전히 혼합되어 나타나기 때문에이 중 하나도 없습니다. 함수의 나머지 코드와 함께).

한편, 성공과 실패의 두 경우 모두 공통된 조치를 취하는 것이 좋습니다. 예를 들어 일련의 네트워크 작업을 직렬화하는 것으로 생각하십시오. 한 작업이 완료되면 이전 작업이 성공 또는 실패로 완료되었을 때 다음 작업을 실행합니다. 이것은 2- 블록 접근법을 사용하는 경우 코드 복제를하는 경우입니다.

전반적으로 두 가지 접근 방식 모두에서해야 할 일을 쉽게 수행 할 수 있기 때문에 큰 차이는 없다고 생각합니다. 그러나 특정 경우에는 한 가지 접근 방식이 다른 방식보다 나은 워크 플로우를 제공 할 수 있습니다.

그냥 2 센트입니다.

Answer 2

2 블록 접근 방식이 "더 깨끗합니다". if/else 블록이 필요하지 않으므로 오류 처리를 더 잘 분리 할 수 ​​있습니다. 또한 1 줄이 적습니다. 전반적으로 큰 차이는 아니지만 코드를 조금 더 세련되고 읽기 쉽게 유지하는 데 도움이됩니다.

제가 생각하기에 다른 두 가지 점은 오류 처리가 자동으로 끝까지 푸시된다는 것입니다. 나는 "무언가 잘못되었을 때를 제외하고는이 모든 것들을하라"라는 형식의 코드를 선호한다. "무언가가 잘못되었다고 가정하라! 그렇지 않았다. 오, 계속해라." 스타일. 어쩌면 나는 낙천주의 자다. 어쨌든, 나는 중요한 부분을 맨위로보고 에러 처리 방법을 보았습니다.

Answer 3

나는 # 1을 선호합니다. 클라이언트 코드가 실제 오류가 무엇인지, 그리고 현재 상황에서 NSError 인스턴스가 되돌아 오는 것을 기반으로 무엇을 의미하는지 결정해야합니다.

옵션 2에서는 완료 블록에 뷰 컨트롤러에서 사용되는 것처럼 보이는 몇 줄 이상의 코드가 포함되어있는 경우 동일한 완료를 많이 실행하려는 가능성이 큽니다 오류가 발생했는지 여부에 관계없이 두 블록의 코드 (UI 업데이트, 일부 상태 복원 등). 이로 인해 불필요한 코드 중복이 발생합니다.

또한 오류 케이스에 신경 쓰지 않는다면 옵션 # 1은 코드가 적습니다.

Answer 4

두 블록 접근 방식으로 해결했습니다. 장점은 다음과 같습니다 이제까지

어떤 순서의 문제 또는 필요하지 않은 경우

그것은 개체 및 오류를 반환 수 있습니다

• , 혹시을 추가하면 어느
• 호출 할 수있는 하나 또는 둘 모두 여부 세 번째 변수를 다른 콜백으로 바꾸면 상황이 훨씬 덜 번잡 해집니다.

내 생각에는 여러 블록을 순차 콜백을 위해 여러 개 예약해야합니다. UIView 애니메이션이 작동하는 방식을 생각해보십시오.

Answer 5

@sergio가 언급하기 때문에 oneBlock 접근법이 더 깨끗하다고 ​​생각합니다. 호출자는 코드 경로를보다 융통성있게 관리 할 수 ​​있습니다. ,

-(void)oneBlock { 
    [self startWithCompletionBlock:^(id obj, NSError* error) { 
     if (error) { 
      NSLog(@"error: %@", error); 
     } else { 
      NSLog(@"success: %@", obj); 
     } 
     self.connection = nil; 
     dispatch_async(dispatch_get_main_queue(), ^{ 
      [self updateUI]; 
     }); 
    }]; 
} 

을 또한 성공 블록이 긴 경우 twoBlocks이 같은 콜백 API를, 그것은 성공의 여부, 자주 정리 (또는 다음 단계) 콜백의 끝에서 호출해야하는 코드가있다 단지 불충분하게 읽습니다 :

-(void)twoBlocks { 
    [self startWithCompletionBlock:^(id obj) { 
     [self doSomething]; 
     [self doSomethingElse]; 

     [self setUpSomeOtherRequestWithCompletionBlock:^(id obj) { 
      [self doSomething]; 
      [self doSomethingElse]; 

      NSLog(@"inside request succeeded"); 
     } errorBlock:^(NSError* error) { 
      NSLog(@"error: %@", error); 
     }]; 

     dispatch_async(dispatch_get_main_queue(), ^{ 
      [self updateUI]; 
     }); 
    } errorBlock:^(NSError* error) { 
     NSLog(@"error: %@", error); 
    }]; 
}