Clean ABAP ⑤ 클래스 설계: 정적 클래스, 상속, FINAL, 생성자

3줄 요약

• 정적 클래스보다 객체를, 상속보다 합성을 먼저 고려하고, 상속을 설계하지 않은 클래스는 FINAL 로 막아요.

• 멤버는 기본 PRIVATE, 값이 안 바뀌는 객체는 getter 대신 public READ-ONLY 속성도 괜찮아요.

• 생성은 NEW, 생성 방식이 여러 가지면 선택 파라미터 대신 new_from_... 같은 정적 생성 메서드로 나눠요.

어떤 상황에서 쓰나요

ABAP 클래스를 새로 설계하거나 리뷰할 때, "이거 static 으로 해도 되지 않나?", "상속으로 풀까?" 하는 질문이 나와요. Clean ABAP 의 클래스 장은 그 질문에 대한 기본 답을 줘요. 이 장은 크게 객체지향, 범위, 생성자 세 묶음이에요.

핵심 내용

객체지향

• 정적 클래스는 거의 쓰지 않아요. 정적 클래스는 유닛 테스트에서 의존성을 테스트 더블로 바꾸기 어렵게 만들어요. 허용되는 예외는 trim 처럼 ABAP 문장이나 내장 함수처럼 보이는 상태 없는 유틸 클래스인데, 쓰는 쪽이 아예 모킹하고 싶지 않을 만큼 기본적인 것에 한해요.

• 상속보다 합성. 올바른 상속은 리스코프 치환 원칙을 지켜야 하고, 계층 구조의 뜻을 읽는 사람이 이해해야 하며, 멤버를 옮기면 계층 전체를 고쳐야 해요. 작고 독립적인 객체를 위임과 퍼사드로 엮는 쪽이 안전해요. 그렇다고 상속을 금지하는 것은 아니고, 복합체(Composite) 패턴처럼 맞는 자리가 있어요.

• 상태 있는 코드와 없는 코드를 한 클래스에 섞지 않아요. 입력만으로 결과가 정해지는 클래스(xml_converter)와 내부 상태를 바꾸는 클래스(log)는 둘 다 괜찮지만, 섞으면 이월 오류와 동기화 문제가 생겨요.

범위

• 기본은 전역 클래스예요. 로컬 클래스는 이터레이터 같은 아주 특수한 내부 구조, 복잡한 비공개 알고리즘 분리, DB 접근을 한곳에 모아 테스트 더블로 바꾸는 용도에 알맞아요. 로컬 클래스는 다른 곳에서 재사용하기 어렵고(찾지도 못해요), 긴 인클루드를 탐색하고 디버깅하기 불편하며, ABAP 은 인클루드 단위로 잠가서 여러 사람이 동시에 작업하기 어려워요.

• 상속을 염두에 두지 않았다면 FINAL 로 막아요. 상속을 열려면 PROTECTED 와 PRIVATE, 치환 원칙, 굳어지는 내부 설계를 같이 생각해야 하기 때문이에요. 다만 인터페이스를 구현하지 않은 지저분한 클래스는 소비자가 유닛 테스트에서 모킹할 수 있게 FINAL 을 붙이지 않는 편이 나아요.

• 멤버는 기본 PRIVATE. 서브클래스가 재정의하게 하려는 것만 PROTECTED 로 해요.

• 값이 생성 뒤 안 바뀌는 객체(immutable)라면 getter 메서드 대신 DATA a TYPE i READ-ONLY. 를 쓸 수 있어요. 값이 바뀌는 객체에는 쓰지 않아요.

• READ-ONLY 는 아껴 써요. PUBLIC SECTION 에서만 되고, 클래스 안과 서브클래스에서는 자유롭게 바꿀 수 있어서 다른 언어의 "한 번 쓰면 못 바꿈"과 달라요.

생성자

• CREATE OBJECT 대신 NEW 를 써요. 동적 타입이 필요할 때만 CREATE OBJECT ... TYPE (dynamic_type) 이에요.

DATA(object) = NEW /clean/some_number_range( '/CLEAN/CXTGEN' ).

• 전역 클래스가 CREATE PRIVATE 여도 CONSTRUCTOR 는 PUBLIC SECTION 에 둬요. 모순 같지만 ABAP 도움말이 컴파일과 문법 검사를 위해 그렇게 요구한다고 해요. 로컬 클래스는 원래대로 private 으로 두고요.

• 생성 방식이 여러 가지면 선택 파라미터를 잔뜩 둔 생성자 대신 describe_by_data, describe_by_name 처럼 이름이 다른 정적 생성 메서드로 나눠요. ABAP 은 오버로딩이 없어서예요. 이름은 new_, create_, construct_ 로 시작하면 new_from_template 처럼 읽혀요(create_1, create_2 는 안 돼요). 복잡하면 빌더 패턴도 고려해요.

• 싱글톤은 "인스턴스가 둘이면 의미가 없다"는 설계상 이유가 있을 때만 써요. 습관이나 성능 때문에 쓰면 뜻밖의 교차 영향과 테스트의 어려움이 생겨요.

주의할 점

• 상속 계층이 이미 깊은 레거시 프로그램에서 이 장을 그대로 적용하면 변경 범위가 커질 수 있어요. 가이드도 상속을 금지하지 않고 "의심스러우면 합성"이라고 해요.

• FINAL 과 모킹에 대한 조언은 서로 당기는 부분이 있어요(FINAL 로 막으면 테스트에서 상속으로 모킹하기 어려워요). 인터페이스 뒤에 두는 설계가 이 충돌을 푸는 방법이라고 가이드는 봐요. 이 연재의 다음 회에서 이어져요.

• 원문은 2019년에 처음 공개되어 2025년 3월에 마지막으로 고쳐졌어요. 이 글은 원문을 읽고 정리한 것이고, 코드를 직접 실행해 보지는 않았어요.

원문 주소: https://github.com/SAP/styleguides/blob/main/clean-abap/CleanABAP.md#classes