ABAP 클린 코드 - METHOD 메서드 (파라미터 유형) [10-4]

“EXPORTING보다 RETURNING을 사용하라“는 ABAP 코딩 스타일 가이드에서 권장하는 지침으로, 메서드나 함수가 단일 값을 반환할 때는 EXPORTING 파라미터 대신 RETURNING 파라미터를 사용하라는 의미입니다. 이는 코드의 간결성, 가독성, 일관성을 높이기 위해서입니다.

 

RETURNING과 EXPORTING의 차이점

 

RETURNING

• 단일 값을 반환할 때 사용됩니다.
• 메서드나 함수 호출 결과를 바로 할당할 수 있어 코드가 더 간결해집니다.
• 보통 핵심적인 반환값이 있는 경우에 사용되며, 메서드나 함수가 값을 반환하는 의도가 명확해집니다.

* RETURNING 사용
METHOD calculate_sum.
  RETURNING VALUE(rv_sum) TYPE i.
  rv_sum = iv_num1 + iv_num2.
ENDMETHOD.

DATA(lv_result) = calculate_sum( 5, 10 ).

 

EXPORTING

• 복수의 값을 반환할 때 사용되며, 함수나 메서드가 여러 결과를 반환해야 할 때 유용합니다.
• 그러나 EXPORTING은 코드가 더 복잡해질 수 있으며, 메서드의 반환값이 명확하게 드러나지 않을 수 있습니다.

* EXPORTING 사용
METHOD calculate.
  EXPORTING
    ev_sum   TYPE i
    ev_diff  TYPE i.
  ev_sum = iv_num1 + iv_num2.
  ev_diff = iv_num1 - iv_num2.
ENDMETHOD.

DATA: lv_sum TYPE i, lv_diff TYPE i.
CALL METHOD calculate
  EXPORTING
    ev_sum = lv_sum
    ev_diff = lv_diff.

 

언제 EXPORTING을 사용해야 할까?

 

• 복수의 값을 반환해야 하는 경우에는 EXPORTING을 사용하는 것이 더 적합합니다. RETURNING은 단일 값만 반환할 수 있기 때문에, 복수의 결과를 반환해야 할 때는 EXPORTING을 사용할 수 있습니다.
• 상태 변경이나 부수 효과(side effect)를 처리할 필요가 있을 때 EXPORTING이 유용할 수 있습니다. 하지만 이 경우도 가능하면 상태 변경을 최소화하고, 메서드의 반환값이 명확히 드러나도록 설계하는 것이 좋습니다.

“EXPORTING보다 RETURNING을 사용하라“는 단일 값을 반환할 때는 EXPORTING보다 RETURNING을 사용하는 것이 더 바람직하다는 지침입니다. RETURNING을 사용하면 코드가 더 간결해지고, 반환값이 명확해지며, 코드의 일관성과 가독성이 향상됩니다. 복수의 값을 반환해야 하는 경우가 아니라면, 가능하면 RETURNING을 사용해 메서드의 반환 동작을 명확하게 표현하는 것이 좋습니다.

 

“큰 테이블을 다룰 때는 RETURNING을 사용하라“는 ABAP에서 메서드나 함수가 대용량 데이터를 다룰 때, EXPORTING이나 CHANGING 대신 RETURNING 구문을 사용하는 것이 더 나을 수 있다는 의미입니다. 이 지침은 메모리 관리와 가독성을 개선하고, 코드의 안전성을 높이기 위한 것입니다.

 

RETURNING이 더 나은 이유

 

1. 메모리 관리

• ABAP에서는 RETURNING 구문을 사용하면 내부적으로 참조 전달 방식이 사용될 수 있습니다. 즉, 반환된 데이터가 바로 할당되고, 불필요한 데이터 복사가 줄어듭니다. 이 방식은 큰 테이블을 처리할 때 성능상의 이점을 가져올 수 있습니다.
• EXPORTING과 CHANGING 구문은 데이터 복사를 동반할 수 있어, 대량의 데이터를 다룰 때 성능 저하를 초래할 수 있습니다.

2. 가독성 및 일관성

• RETURNING 구문을 사용하면 메서드나 함수의 목적이 더 명확해집니다. 데이터 처리가 완료되면 결과를 반환하는 형태로 코드를 작성할 수 있어, 가독성이 좋아집니다.
• EXPORTING이나 CHANGING을 사용할 경우, 함수나 메서드 내부에서 데이터를 조작하는 방식이 드러나지 않을 수 있습니다. 하지만 RETURNING은 함수가 특정 데이터를 반환하는 것을 명확하게 표현합니다.

3. 안전성

• CHANGING 구문을 사용하면 전달된 데이터를 함수나 메서드 내에서 변경할 수 있는데, 이는 예상치 못한 부작용을 초래할 수 있습니다. RETURNING 구문을 사용하면 함수가 반환하는 데이터를 명확하게 할당받을 수 있어, 더 안전한 코드를 작성할 수 있습니다.

4. 테스트 용이성

• RETURNING을 사용하면 메서드나 함수의 결과가 명확히 드러나므로, 테스트가 더 쉬워집니다. 반환된 데이터를 바로 검증할 수 있어, 테스트 코드 작성 시 더 직관적으로 접근할 수 있습니다.

“큰 테이블을 다룰 때는 RETURNING을 사용하라“는 메서드나 함수가 대용량 데이터를 처리할 때, EXPORTING이나 CHANGING 대신 RETURNING 구문을 사용해 성능을 최적화하고 코드의 가독성과 안정성을 높이자는 의미입니다. RETURNING을 사용하면 메모리 관리 측면에서 더 효율적일 수 있으며, 코드의 의도가 명확해져 유지보수와 테스트가 용이해집니다.

 

“RETURNING, EXPORTING, CHANGING 중 하나만 사용하고 혼합하지 마라“는 메서드나 함수에서 값을 반환할 때 하나의 방식만 사용하라는 지침입니다. 즉, RETURNING, EXPORTING, CHANGING 중 하나의 방식만 선택하고, 혼용하지 말아야 한다는 것입니다. 이 지침은 코드의 일관성, 가독성, 유지보수성을 높이기 위한 설계 원칙입니다.

 

혼합 사용의 단점

 

1. 복잡성 증가

• 메서드나 함수에서 여러 반환 방식을 혼합하여 사용하면, 코드가 복잡해지고 메서드의 의도가 불명확해집니다. 호출자는 메서드가 어떤 방식으로 값을 반환하는지 한눈에 파악하기 어려워집니다.

2. 가독성 저하

• 반환 방식이 혼합되면 메서드의 동작을 이해하는 데 시간이 걸립니다. 메서드 내부에서 반환값이 어떻게 처리되는지 추적해야 하므로 코드의 가독성이 떨어집니다.

3. 유지보수 어려움

• 여러 방식이 혼합된 코드는 유지보수가 어렵습니다. 메서드의 인터페이스가 변경될 때, 모든 호출부를 수정해야 할 가능성이 커지고, 의도하지 않은 동작을 초래할 수 있습니다.

4. 테스트 복잡성 증가

• 반환 방식이 혼합되면, 테스트 시 모든 반환 값을 일일이 확인해야 하므로 테스트 코드도 복잡해집니다. 일관된 방식으로 반환되는 값이 적을수록 테스트가 더 쉽고 명확해집니다.

* 잘못된 패턴
METHOD calculate_values.
  EXPORTING
    ev_sum TYPE i.
  CHANGING
    cv_difference TYPE i.
  RETURNING
    VALUE(rv_product) TYPE i.

  ev_sum = iv_num1 + iv_num2.
  cv_difference = iv_num1 - iv_num2.
  rv_product = iv_num1 * iv_num2.
ENDMETHOD.

 

RETURNING

• 단일 값을 반환할 때 사용합니다. 메서드가 하나의 주요 결과를 반환할 때, 반환값을 바로 할당할 수 있어 간결하고 직관적입니다.

* RETURNING 만 사용
METHOD calculate_values.
  RETURNING VALUE(rv_product) TYPE i.
  rv_product = iv_num1 * iv_num2.
ENDMETHOD.

 

EXPORTING:

• 복수의 값을 반환할 때 사용합니다. 메서드가 여러 개의 결과를 반환해야 하거나, 반환값이 명확한 경우에 적합합니다.

* EXPORTING 만 사용
METHOD calculate_values.
  EXPORTING
    ev_sum        TYPE i
    ev_difference TYPE i.
  ev_sum = iv_num1 + iv_num2.
  ev_difference = iv_num1 - iv_num2.
ENDMETHOD.

 

CHANGING

• 전달된 값을 변경해야 할 때 사용합니다. 주로 상태를 변경하거나 전달된 값을 조작하는 경우에 적합합니다.

* CHANGING 만 사용
METHOD update_values.
  CHANGING
    cv_value1 TYPE i
    cv_value2 TYPE i.
  cv_value1 = cv_value1 + 10.
  cv_value2 = cv_value2 - 5.
ENDMETHOD.

 

“RETURNING, EXPORTING, CHANGING 중 하나만 사용하고 혼합하지 마라“는 메서드나 함수에서 값을 반환할 때 하나의 방식만 선택하고 일관되게 사용하라는 의미입니다. 이를 통해 코드의 일관성, 가독성, 유지보수성을 높일 수 있습니다. 반환할 값의 종류나 목적에 맞게 적절한 방식을 선택하고, 그 방식을 일관되게 사용하는 것이 좋은 설계의 핵심입니다.

 

“CHANGING을 분별하여 사용하라“는 ABAP 코딩 스타일 가이드에서 CHANGING 파라미터를 신중하고 적절하게 사용하라는 의미입니다. CHANGING 파라미터는 메서드나 함수가 전달받은 파라미터 값을 변경하여 다시 호출자에게 반환할 때 사용됩니다. 그러나, 이 방식은 코드의 명확성과 예측 가능성을 해칠 수 있기 때문에 신중하게 사용해야 한다는 것입니다.

 

CHANGING 파라미터의 특성

 

• 전달된 값 변경: CHANGING 파라미터는 메서드나 함수가 인수로 전달된 데이터를 변경할 수 있도록 합니다. 즉, 호출한 쪽에서 전달한 변수가 메서드나 함수의 내부 동작에 의해 변경됩니다.
• 부작용 위험: CHANGING 파라미터를 사용하면, 함수나 메서드 외부에서 값을 전달한 호출자가 예상치 못한 결과를 겪을 수 있습니다. 특히, 전달된 값이 변경된다는 사실을 놓치면, 코드의 예측 가능성이 떨어지고, 디버깅이 어려워질 수 있습니다.
• 명확한 의도 필요: CHANGING을 사용할 때는 함수나 메서드가 명확한 의도를 가지고 값을 변경해야 합니다. 그렇지 않으면, 코드가 복잡해지고, 호출자에게 불필요한 혼란을 초래할 수 있습니다.

언제 CHANGING을 사용해야 할까?

 

1. 상태 변경이 명확한 경우

• CHANGING은 전달된 데이터의 상태를 변경하는 작업이 명확할 때 유용합니다. 예를 들어, 여러 개의 값이 메서드 내부에서 수정되어야 하고, 수정된 결과가 다시 호출자에게 전달되어야 하는 경우에 적합합니다.
• 호출자는 메서드가 해당 파라미터를 변경할 것이라는 점을 알고 있어야 하며, 코드의 흐름에서 이러한 변경이 자연스럽게 보일 수 있어야 합니다.

* 상태 변경이 명확한 경우
METHOD update_coordinates.
  CHANGING
    cv_x TYPE i
    cv_y TYPE i.
  cv_x = cv_x + 10.
  cv_y = cv_y + 5.
ENDMETHOD.

DATA: lv_x TYPE i VALUE 5, lv_y TYPE i VALUE 10.
CALL METHOD update_coordinates
  CHANGING
    cv_x = lv_x
    cv_y = lv_y.
* lv_x와 lv_y 값이 업데이트됨

 

2. 여러 값을 동시에 수정해야 할 때

• CHANGING은 복수의 값을 동시에 수정해야 하는 경우에 유용할 수 있습니다. 단일 반환값이 아닌, 여러 개의 값이 변경되며 이 변경된 값들이 호출자에게 다시 전달되어야 할 때 사용합니다.

* 여러 값을 동시에 수정이 필요할 때
METHOD adjust_values.
  CHANGING
    cv_value1 TYPE i
    cv_value2 TYPE i.
  cv_value1 = cv_value1 * 2.
  cv_value2 = cv_value2 - 3.
ENDMETHOD.

 

3. 명확한 부수 효과(Side Effect)가 필요한 경우

• CHANGING은 메서드가 특정 작업을 수행하고, 그 결과로 부수 효과가 명확하게 발생할 때 사용할 수 있습니다. 이 경우, CHANGING 파라미터를 사용해 변경된 결과를 명확하게 반환하도록 설계해야 합니다.

* 명확한 부수 효과가 필요할 떄
METHOD update_stock.
  CHANGING
    cv_quantity TYPE i.
  cv_quantity = cv_quantity - 1.
ENDMETHOD.

 

언제 CHANGING을 사용하지 말아야 할까?

 

1. 명확하지 않은 상태 변경

• 메서드나 함수가 데이터를 변경하는지 명확하지 않다면, CHANGING을 사용하지 않는 것이 좋습니다. 상태가 명확하게 관리되지 않으면, 코드의 예측 가능성과 안정성이 떨어집니다.
• 반환값을 통해 데이터를 명확히 전달하는 것이 더 나은 선택일 수 있습니다.

2. 단일 값 반환이 가능한 경우

• 메서드가 단일 결과를 반환하는 경우에는 RETURNING을 사용하는 것이 더 적합합니다. CHANGING은 여러 값을 변경해야 할 때 유용하지만, 단일 값을 변경하는 경우에는 불필요하게 복잡해질 수 있습니다.

3. 메서드의 책임이 명확하지 않은 경우

• 메서드가 너무 많은 책임을 지고 있어 여러 파라미터를 수정해야 하는 경우, CHANGING 사용을 재고해야 합니다.
• 메서드를 분리하여 단일 책임 원칙(SRP)을 적용하는 것이 더 나은 해결책이 될 수 있습니다.

“CHANGING을 분별하여 사용하라“는 상태 변경이 명확하고 필수적인 경우에만 CHANGING 파라미터를 사용하라는 의미입니다. 코드에서 부수 효과(Side Effect)를 명확하게 관리하고, 호출자가 메서드의 동작을 쉽게 이해할 수 있도록 설계해야 합니다. 필요하지 않은 경우에는 RETURNING이나 EXPORTING을 사용해 데이터를 명확히 반환하는 것이 좋으며, 메서드의 책임을 분명히 정의하여 코드의 예측 가능성과 가독성을 유지하는 것이 중요합니다.

 

“Boolean 파라미터를 사용하는 대신에 메서드를 분할하라“는 객체지향 설계에서 Boolean 파라미터(예: TRUE, FALSE 값)를 통해 메서드의 동작을 분기 처리하지 말고, 명확한 역할을 가진 개별 메서드로 분리하라는 지침입니다. 이 원칙은 단일 책임 원칙(Single Responsibility Principle, SRP)을 따르고, 코드의 가독성, 유지보수성을 높이기 위한 설계 방식입니다.

 

Boolean 파라미터 사용의 단점

 

1. 책임의 모호성

• Boolean 파라미터를 사용하는 메서드는 하나의 메서드가 여러 가지 역할을 수행하게 만듭니다. 예를 들어, do_something( iv_flag = abap_true )와 같이 Boolean 플래그를 전달하면, 메서드 내부에서 이 플래그에 따라 서로 다른 동작을 수행하게 됩니다. 이로 인해 메서드의 책임이 모호해지고, 단일 책임 원칙을 위반하게 됩니다.

2. 가독성 저하

• Boolean 파라미터는 코드의 의도를 불분명하게 만듭니다. 메서드를 호출할 때, TRUE나 FALSE 값을 전달하는 것이 어떤 동작을 의미하는지 명확하지 않을 수 있습니다. 이는 코드의 가독성을 떨어뜨리고, 유지보수하는 사람이 메서드의 동작을 쉽게 이해하지 못하게 할 수 있습니다.

3. 테스트 복잡성 증가

• Boolean 파라미터를 사용하면 메서드의 동작이 플래그 값에 따라 달라지므로, 테스트 케이스도 복잡해집니다. 각 플래그의 경우에 대해 테스트해야 하므로, 다양한 시나리오를 처리해야 하며, 이는 테스트 코드의 복잡성을 높입니다.

4. 유지보수 어려움

• 메서드가 Boolean 파라미터에 따라 여러 가지 역할을 하게 되면, 코드가 변경될 때 이 메서드가 모든 역할을 제대로 수행하는지 확인하기 어렵습니다.
• 새로운 요구 사항이 추가될 때 메서드를 확장하는 과정에서 코드가 점점 더 복잡해질 수 있습니다.

메서드 분할

 

1. 명확한 책임 분리

• 각 메서드가 하나의 명확한 역할을 수행하게 됩니다. 이로 인해 코드의 책임이 분명해지고, 단일 책임 원칙을 더 잘 따를 수 있습니다.

2. 가독성 향상

• Boolean 플래그 없이, 메서드 이름 자체가 무엇을 하는지 명확히 표현할 수 있습니다. 코드가 더 직관적이고 읽기 쉬워지며, 호출자가 메서드의 동작을 쉽게 이해할 수 있습니다.

3. 유지보수 용이성

• 개별 메서드로 분리되면 코드 변경이 더 쉬워집니다. 각 메서드가 독립적으로 동작하므로, 새로운 요구 사항이 추가될 때에도 코드 수정의 영향을 최소화할 수 있습니다.

4. 테스트 용이성

• 각 메서드를 독립적으로 테스트할 수 있어, 테스트 코드 작성이 더 간단해집니다. 각 메서드가 특정 동작만을 수행하므로, 테스트 시나리오가 더 명확해지고 테스트 커버리지를 높일 수 있습니다.

* 잘못된 패턴
METHOD process_order.
  IMPORTING
    iv_is_express TYPE abap_bool.

  IF iv_is_express = abap_true.
*     Express 주문 처리 로직
  ELSE.
*     일반 주문 처리 로직
  ENDIF.
ENDMETHOD.

 

* 올바른 패턴
METHOD process_express_order.
*   Express 주문 처리 로직
ENDMETHOD.

METHOD process_regular_order.
*   일반 주문 처리 로직
ENDMETHOD.

 

언제 Boolean 파라미터를 사용할 수 있을까?

• Boolean 파라미터를 사용하는 것이 적합할 때도 있습니다. 예를 들어, 메서드가 수행하는 주요 작업에 큰 영향을 주지 않고, 작은 분기를 처리하는 경우 Boolean 파라미터를 사용할 수 있습니다. 그러나, 이 경우에도 메서드의 책임이 단일하고, 가독성이 유지되는지 신중하게 고려해야 합니다.

“Boolean 파라미터를 사용하는 대신에 메서드를 분할하라“는 메서드가 Boolean 파라미터에 따라 여러 역할을 수행하지 않도록, 하나의 역할만 수행하도록 메서드를 분리하라는 의미입니다. 이를 통해 코드의 가독성, 유지보수성, 테스트 용이성이 향상되며, 객체지향 설계 원칙을 더 잘 준수할 수 있습니다. 코드의 의도를 명확히 표현하고, 각 메서드가 단일 책임을 가지도록 설계하는 것이 중요합니다.