인프런 커뮤니티 질문&답변

강명덕님 좋은 질문 남겨 주셔서 감사합니다!

두 질문에 대해 차례대로 답변드릴게요. 🙂

1. 협력을 위해 제공하는 메시지를 확인하기 용이하기 때문인가요?

먼저 첫 번째 질문인 “추상 클래스로만 추상화를 한 뒤, 상위 수준 객체가 인터페이스 대신 추상 클래스를 의존하면 안될까?”에 대해 답변 드릴게요.

강의에서 설명드렸던 것처럼 JsonReader와 CsvReader에서 추상화를 추출하는 이유는 클라이언트인 CallCollector 입장에서 두 객체가 교체 가능해야 하기 때문입니다.

이를 위해서는 CallCollector가 구체적인 JsonReader나 CsvReader에 의존하는 대신 두 타입의 객체를 포괄하는 상위 타입에만 의존하도록 의존성을 조정해야 합니다.

여기에서 고민은 말씀하신 것처럼 Reader를 인터페이스 대신 추상 클래스로 만들 것인지, 아니면 인터페이스로 만들고 중복 코드는 추상 클래스인 AbstractReader에 남기는 안을 선택할 지를 결정해여 한다는 것입니다.

강의와 다르게 Reader를 추상 클래스로 선언하면 말씀하신 것처럼 read만 public이기 때문에

public abstract class Reader {
  private String path;
  
  public Reader(String path) {
    this.path = path;
  }
  
  public List<Call> read() {  
    List<String> lines = readLines(path);    
    return parse(lines);  
  }  
  
  private List<String> readLines(String path) {    
    try {      
      return Files.readAllLines(
        Path.of(ClassLoader.getSystemResource(path).toURI()));
     } catch (Exception e) {       
        throw new RuntimeException(e);    
     }  
  }
  
  protected abstract List<Call> parse(List<String> lines);
}

CallCollector는 추상 클래스인 Reader를 의존성 주입받아서 사용하면 되겠죠.

public class CallCollector {  
  private final Reader reader;  
  
  public CallCollector(Reader reader) {    
    this.reader = reader;  
  }  
  
  public CallHistory collect(String phone) {    
    List<Call> calls = reader.read();
    ...
  }
}

이렇게 구현을 해도 CsvReader와 JsonReader를 교체하겠다는 목표는 달성할 수 있습니다.

여기에서 7-3을 포함하는 섹션7의 타이틀을 “외부 의존성과 테스트”라고 지었다는 점에 주목해 주시면 좋겠습니다.

지금 우리는 CallCollector를 좀 더 쉽게 테스트하고 싶다는 점도 목표로 하고 있습니다.

테스트 관점에서 현재의 Reader에서 신경 쓰이는 부분은 Reader가 외부의 파일 시스템에 의존하고 있다는 점입니다.

Reader의 내부 구현은 런타임에 파일 시스템이 존재한다는 것을 가정하고 있습니다.

단위 테스트는 외부의 파일 시스템에 의존하지 않고 메모리 안에 생성된 객체들을 이용해서 실행하는 것이 이상적이기 때문에 파일에 대한 의존성을 제거하고 테스트할 수 있다면 좋겠죠.

Reader를 인터페이스로 만들면 파일에 대한 의존성을 제거할 수 있습니다.

public interface Reader {  
  List<Call> read();
}

파일에 대한 의존성은 AbstractReader로 이동시켰습니다.

public abstract class AbstractReader implements Reader {
  private String path;
  
  public Reader(String path) {
    this.path = path;
  }
  
  public List<Call> read() {  
    List<String> lines = readLines(path);    
    return parse(lines);  
  }  
  
  private List<String> readLines(String path) {    
    try {      
      return Files.readAllLines(
        Path.of(ClassLoader.getSystemResource(path).toURI()));
     } catch (Exception e) {       
        throw new RuntimeException(e);    
     }  
  }
  
  protected abstract List<Call> parse(List<String> lines);
}

이제 CallCollector는 파일에 대한 의존성을 가지지 않는 Reader 인터페이스에만 의존하기 때문에 쉽게 외부 의존성을 고려하지 않고도 쉽게 테스트할 수 있습니다.

실제로 7-3의 11:07 부분을 보시면 가짜 객체(Fake Object) 방식으로 구현된 테스트 더블인 FakeReader를 이용해서 단위 테스트를 쉽게 실행할 수 있는 방법을 보여주고 있습니다.

public class FakeReader implements Reader {  
  private List<Call> calls;  
  
  public FakeReader(Call ... calls) {    
    this.calls = List.of(calls);  
  }
  
  @Override  
  public List<Call> read() {    
    return calls;  
  }
}

물론 Reader가 추상 클래스인 경우에도 가짜 객체를 추가할 수는 있습니다.

하지만 추상 클래스의 경우에는 Reader의 내부 구현을 이해한 상태에서 가짜 객체를 구현해야 하기 때문에 복잡해집니다.

다음은 Reader가 추상 클래스인 경우의 FakeReader 구현입니다.

public class FakeReader extends Reader {
    private List<Call> calls;

    public FakeReader(Call ... calls) {
        super("");
        this.calls = List.of(calls);
    }

    @Override
    public List<Call> read() {
        return calls;
    }

    @Override
    protected List<Call> parse(List<String> lines) {
        return List.of();
    }
}

상속은 내부 구현에 대한 결합도가 높기 때문에 내부 구현을 이해해야 한다는 점이 항상 문제를 일으킵니다.

FakeReader를 구현하기 위해서는 Reader의 내부 구현을 이해해야 합니다.

read 메서드만 오버라이딩하면 파일에 대한 의존성을 제거할 수 있다는 사실을 이해해야 합니다.

FakeReader의 생성자에서 super 콜을 이용해서 Reader의 생성자를 호출해야 한다는 사실을 알고 있어야 합니다.

Reader의 내부 구현에 속하지만 테스트와는 상관이 없는 parse 메서드도 오버로딩해야 합니다.

이 경우에는 테스트를 위해 내부 구현에 대한 결합을 완전히 끊어내기 위해 인터페이스를 사용하는게 더 효과적입니다.

말씀하신 것처럼 인터페이스가 추상 클래스보다 역할을 한 눈에 파악하기 쉬운건 맞지만 설계 원칙을 기반으로 추상 클래스를 작게 만들 경우에는 이 부분에서 생각보다 차이가 크지는 않은 것 같아요.

인터페이스를 하나 추가할 때의 비용(머리 속에서 트래킹해야 하는 요소가 하나 추사된 거니까요) 대비 이익이 크지 않다면 추상 클래스로 시작하시는게 좋습니다.

이런 이슈가 발생하지 않고 단위 테스트 관점에서 큰 차이가 없는 경우라면 저도 강명덕님의 생각과 동일하게 추상 클래스로 시작했을 겁니다.

나중에 여러 클래스 계층에 적용할 필요가 있는 경우에 인터페이스를 추출하는건 생각보다 쉽기 때문이죠.

2. 두 public 메서드 중 하나는 중복 로직, 하나는 각 구현체마다 다르게 구현하는 경우에도 인터페이스와 추상클래스를 함께 사용하는 것이 좋을까요?

모든 자식 클래스들이 단일 상속 계층 안에 위치하는지 여부와 단위 테스트에 대한 필요성에 따라 판단하시면 될것 같습니다.

• 만약 자식 클래스들이 여러 상속 계층을 구성한다면 인터페이스로 만드시는게 좋습니다.

• 동일한 상속 계층에만 속한다면 인터페이스와 추상 클래스 둘 중 하나를 선택할 수 있습니다.

• CaptchaHashProcessor와 협력하는 다른 클래스를 단위 테스트해야 한다면 verify 메서드의 내부 구현이 통제하기 어려운 외부 요소에 의존하고 있는지 살펴보시는게 좋습니다.

• 만약 verify 메서드가 불안정한 외부 요소를 사용한다면 인터페이스로 만드시는게 모킹이나 가짜 객체를 만들기에 용이합니다.

• 만약 verify 메서드가 통제 가능한 요소들만 사용한다면 추상 클래스로 만드셔도 무방합니다.

이렇게 모든 클래스가 단일 상속 계층에 속하고 불안정한 요소게 의존하지 않기 때문에 단위 테스트에 문제를 일으키지 않는다면 말씀하신 것처럼 일단 추상 클래스에 의존하도록 만드셔도 무방합니다.

대신에 추상 클래스의 이름은 Abstract를 제외한 CaptchaHashProcessor로 지으시는게 좋습니다.

이렇게 하면 나중에 CaptchaHashProcessor를 인터페이스로 변경하더라도 클라이언트에 주는 영향을 최소화할 수 있습니다.

중복을 제거하고 코드를 더 쉽게 재사용할 수 있는 더 좋은 방법으로는 합성(Composition)이 있으며 색션 8에서 관련된 내용을 다루고 있습니다.

질문의 내용 구성에 대해 의견을 요청하셨는데 궁금하신 내용을 명확하게 정리해 주셔서 답변을 드리기가 쉬웠습니다.

질문도 흥미로운 부분이라 강의에서 해당 부분을 좀더 자세히 설명했으면 좋았었겠구나라는 생각이 들었습니다.

좋은 질문해 주셔서 감사드리고 답변 중에 미진한 부분이나 추가로 궁금한 부분 있으면 질문 남겨주시면 감사하겠습니다!