2009-06-19 4 views
1

얼마나 많은 정보 숨기기가 필요합니까?코드 리팩토링을 수행 할 때 정보 숨기기가 얼마나 필요합니까?

public override void OrderProcessing_Delete(Dictionary<string, object> pkColumns) 
    { 
     var c = Connect(); 


     using (var cmd = new NpgsqlCommand("SELECT COUNT(*) FROM orders WHERE order_id = :_order_id", c) 
      { Parameters = { {"_order_id", pkColumns["order_id"]} } }) 
     { 
      var count = (long)cmd.ExecuteScalar(); 

      // deletion's boilerplate code... 
      if (count == 0) throw new RecordNotFoundException(); 
      else if (count > 1) throw new DatabaseStructureChangedException(); 
      // ...boiler plate code 
     } 



     // deleting of table(s) goes here... 
    } 

참고 : 나는 기록을 삭제하기 전에 내가 상용구 코드를 가지고, 그것은 다음과 같습니다 상용구 코드는 "사용 (var에 cmd를 = 새로운 NpgsqlCommand (...)"

포함, 코드 생성

using (var cmd = new NpgsqlCommand("SELECT COUNT(*) FROM orders WHERE order_id = :_order_id", c) 
     { Parameters = { {"_order_id", pkColumns["order_id"]} } }) 
    { 
       cmd.VerifyDeletion(); // [EDIT: was ExecuteWithVerification before] 
    } 
() 확장 메서드 (안 유일한 이유 좋네요했다).

하지만 심각 이것은 내가 코드를 리팩토링하는 구상 어떻게 내가 더 간결 코드를 원, 보일러 플레이트 코드를 리팩토링 생각하고

startscalar 코드와 상용구 코드가 확장 메서드 안에 들어가기를 바랬다.

위 코드의 경우 코드 리팩터링/정보 숨김이 필요합니까? 리팩터링 된 작업이 너무 불투명 해 보입니까?

답변

2

새 단 한 줄의 코드가 프로그램의 여러 위치에있는 코드 줄을 바꿔 버리면 리펙터가 매우 좋다고 말할 수 있습니다. 특히 그 기능이 모든 장소에서 동일 할 것이기 때문에 특히 그렇습니다.

프로그래머가 코드를보고 나면 코드가 무엇인지 알아 내기 위해 확장 메서드의 정의를 살펴보고 이제는이 코드가 한 곳에서 정의된다는 것을 알고 있으므로 그것은 장소마다 다르다.

+0

VerifyDeletion은 (적어도 내 코드의 경우에는) 잘 정의 된 기능이므로이 메소드를 확장 메소드 – Hao

0

코드를 추출하거나 리팩터링 할 때 정보를 숨기지 않습니다. 리팩터링 후 확장 정의에 대한 액세스를 제한하기 시작할 때만 정보를 숨기는 것입니다.

1

꼭 해봐야 겠지만 내 느낌은 간결한 것이 아니고 때마다 또는 대부분의 시간대에 적용하려고하는지 여부입니다. 그리고 확장을 통해 검증 조건이 변경되면 보드 전체에서 변경 될 수 있습니다.

기본적으로 보일러 플레이트 코드의 작은 덩어리를 줄이면 반드시 간결해질 수는 없습니다. 이것은 개발자가 이해하고 이해해야 할 추상성의 비트입니다.

개발자는 "ExecuteWithVerify"가 무엇을 의미하는지 알 수 없습니다. 우리가 정확히 무엇을 확인하고 있습니까? 나는 그것을보고 기억해야 할 것입니다. 그러나 보일러 - 플레이트 코드를 사용하면 코드를보고 정확히 무슨 일이 일어나는지 알 수 있습니다.

별도의 방법으로 축소하지 않음으로써 다른 조건에 예외를 던져야하는 경우에 대비하여 보일러 플레이트 코드를 조정할 수도 있습니다.

+0

에 넣어야한다는 데 동의합니다. 응답 # 1은 리팩토링을위한 인수를 제공했기 때문에 내 인수가 이에 대한 인수입니다. 기본적으로, 현재 코드가 "미래"를 요구한다면 refactor가 – hythlodayr

-1

클래스 내의 "new"연산자 (생성자 제외)는 어떤 경우에도 사용하지 않아야합니다. 이것이 당신이 여기서 리팩터링 할 필요가있는 것입니다.

관련 문제