영암사는 승경이네

 생각만해도 한숨이 턱~ 나오는 나의 인생 첫 기술면접... 컨디션 관리도 제대로 못하고, 너무 긴장한 탓에 쉬운 질문도 이해되지 않았다. 어두컴컴했던 인터뷰를 복기하고나니 내가 개선해야할 점을 아주 확실하게! 찾아낼 수 있었다. 장담컨데 다음 기술면접은 이렇게 쭈구리처럼 보지 않을 것 같다! (기업 명은 비밀!)

1. 면접 전날...

 면접 전날부터 심장이 벌렁벌렁거렸다. 생애 처음 넣은 이력서가 서류 합격, 과제테스트 합격, 기술면접까지 가리라곤 생각지 못했기 때문이다. 물론 현업 경력은 있지만 해당 기업은 학교에서 연결해주던 곳이었고, 정석적인 채용 절차를 거치지 않았었다. 어쨌든 두근거리는 마음과 함께 과제 테스트로 제출한 코드를 복기하며 코드 리뷰를 준비하는데 시간을 쏟아부었다. 

 거의 3주? 정도 전에 완성했던 코드라 복기를 하는데 시간이 조금 걸렸다. 새벽에 준비를 끝마치고 오후 5시경에 있을 기술면접을 생각하며 잠을 청하려고 했다. 그런데... 나의 머가리는 잠을 거부했다. 마치 초등학교 5학년 첫 수학여행을 가기 전날의 두근거림이었다. 머릿속으로 온갖 면접 시뮬레이션을 돌리다보니 어느덧 아침이됐다. @_@;

2. 면접 당일

 아침밥을 먹고 면접 준비를 했다. 화상면접이라 마이크, 카메라, 목소리 등을 체크했다. 면접관님들의 눈을 고려하여 초록색 가상 배경도 준비했다. 그런데 너무 일찍부터 면접 준비를 했다. 만약 이게 대면 면접이었다면 거의 10시간 전에 면접장소에 도착한 격이었다. (홀리몰리) 시간이 많이 남아 자기 소개 연습을 하고 코드를 복기했다.  

3. 면접 5시간 전

 점심밥을 억지로 먹고 다시 화상 카메라 앞에 앉았다. 면접까지 약 5시간 남았었다. 이때부터였나 눈이 뻑뻑해지고 반쯤 감기기 시작했다. 하지만 여기서 잠을 자버리면 나의 첫 기술면접을 꿈에서 볼것같은 예감이 강하게 들었다. 혹시나 이런 생각 도중에 잠이 들어버릴까 겁나 박카스를 사러 편의점으로 뛰어갔다.

4. 면접 30분 전

 박카스를 원샷했다. 내 마지막 발악이었던것 같다.

5. 면접

 면접을 봤다... 결론부터 말하면 면접관님들께 너무 너무 죄송스러웠다. 그 분들도 나라는 사람을 평가하기  위해 시간을 낸것인데, 그 시간이 무색해질 만큼 대답을 하지 못했다. 면접이 끝나자마자 긴장이 풀림과 동시에 잠이 들었다.

 다음날 면접에 나온 질문들을 복기해보며 면접관 님들이 어떤 의도로 질문했는지, 나는 어떻게 답변하는게 좋았을지를 정리해보았다. 솔직히 정말 솔직히 질문은 어렵지 않았다. 아마 나의 답변수준을 보고 질문 수준이 같이 낮아진것 같긴 하지만.. 어쨌든 어렵지 않은 질문을 이해하지 못한 것과 그때 내 생각을 자신감 있게 전달하지 못한 점. 무엇보다 내가 가진 지식에 대한 확신을 가지지 못한 점이 너무 후회스러웠다. 

6. 질문 내용

Q1. userService.getUserInfo 메서드를 테스트하고 assertThat으로 검증하고 있으며, userRepository.findById 리턴 값을 USER_FOR_VALID_USER_ID 로 목킹하고 있다. assertThat 구문으로 동일한(?) 값을 굳이 검증한 이유가 뭔가?

@DisplayName("유효한 ID에 대한 유저 정보 조회")
    @Test
    void getUserInfoWithValidUserId(){
        given(userRepository.findById(any(String.class)))
                .willReturn(Optional.of(USER_FOR_VALID_USER_ID));

        given(aes256.decrypt(any(String.class)))
                .willReturn(AES256_DEC_REG_NO);

        UserDto.Info userInfo = userService.getUserInfo(VALID_USER_ID);

        assertThat(userInfo.getUserId()).isEqualTo(USER_INFO_FOR_VALID_USER_ID.getUserId());
        assertThat(userInfo.getName()).isEqualTo(USER_INFO_FOR_VALID_USER_ID.getName());
        assertThat(userInfo.getRegNo()).isEqualTo(USER_INFO_FOR_VALID_USER_ID.getRegNo());
    }

그때 당시 질문를 이해하지 못해 진정한 개소리를 했다. 트루 개소리였다. 되돌아보니 면접관님께서 USER_FOR_VALID_USER_ID와 USER_INFO_FOR_VALID_USER_ID를 동일한 인스턴스로 착각하고 물어보신것 같다. 변수명이 비슷해서 나도 착각했기 때문이다.

어찌됐든 면접관님의 질문 의도는 “userRepositroy에서 A를 리턴하도록 목킹하고, 서비스 클래스에서는 이를 그대로 리턴하는 것 같은데 테스트 코드에서 A의 필드에 대해 따로따로 검증한 이유가 뭐냐. 그냥 A 인스턴스 자체를 체크하면 되지 않냐” 였던 것 같다.

# 돌아갈 수 있다면...

USER_FOR_VALID_USER_ID는 엔티티이며, USER_INFO_FOR_VALID_USER_ID는 해당 엔티티를 통해 최종적으로 리턴되는 유저 정보 DTO 클래스입니다. UserService.getUserInfo 메서드에서는 조회된 엔티티에 대해 주민등록번호 복호화, 마스킹처리, DTO 변환 작업을 수행합니다. 이에 대한 응답 테스트 픽스처를 USER_INFO_FOR_VALID_USER_ID로 정의했으며, 이 값들을 비교하기 위해 각 필드에 대해assertThat 을 사용하여 체크하였습니다.

Q2-1. aes256을 빈으로 등록하고 있는데, 혹시 빈으로 등록하는 본인만의 기준이 있는지

 AES256 암복호화 클래스는 빈으로, SHA256 암호화 클래스는 일반 클래스로 두고, 정적 스태틱 메서드로 사용하고 있었다. 어쨌든 성격이 비슷한 이런 클래스들을 빈, 일반 클래스로 구분지어 사용하는 이유를 궁금해하셨던 것 같다.

 AES를 빈으로 사용한 이유는 주저리 주저리 답변은 한것 같지만, 클래스를 빈으로 등록하는 본인만의 기준이 있냐는 질문과 확장성에 대한 답변을 못했다. 생각해본적이 없는 내용이었다. 정신이 말짱했어도 이건 대답을 못했을 것 같다.

 스프링 IoC와 DI 개념을 다시 훑어보니 질문의 의도가 스프링의 기본 개념을 알고있는냐로 이해됐다. 클래스를 빈으로 등록하면 스프링 IoC 컨테이너에 의해 기본 싱글톤으로 관리되며, 이렇게 관리되는 빈들은 런타임 시 스프링에서 제공하는 여러 기능을 사용할 수 있다.

 생성자 메서드만 만들어 놓으면 자동으로 의존 주입이 되고, 빈으로 등록된 클래스에 @Transactional 어노테이션을 사용하면 트랜잭션이 적용되고, @Controller 어노테이션을 사용한 클래스가 서블릿으로 사용되고, @PostMapping, @GetMapping 어노테이션들이 기능으로써 동작한다.

 단순 어노테이션이 이렇게 어떤 기능으로써 동작할 수 있는 가장 첫번째 이유는 해당 클래스가 '빈'이기 때문이다. 내부적으로 IoC 컨테이너에서 관리되는 빈 리스트를 읽은 후 리플렉션과 프록시 등을 통해 이러한 기능들을 부여하기 때문이다. 

# 돌아갈 수 있다면...

 싱글톤으로 관리되며, 스프링에서 제공하는 기능을 사용할 클래스를 빈으로 등록하는 편입니다. 이러한 빈은 스프링에서 제공하는 여러 기능들을 런타임 시 부여할 수 있다는 점에서 확장성을 향상시킨다고 생각합니다.

# SHA256 을 유틸성 클래스로 설계한 이유 및 회고

public class SHA256 {
    public static String encrypt(String plainText){
        try{
            MessageDigest md = MessageDigest.getInstance("SHA-256");
            md.update(plainText.getBytes());
            return bytesToHex(md.digest());
        }catch(Exception e){
            log.error(e.getMessage());
            throw new EncryptException(ErrorMessage.SHA256_ENCRYPT_FAIL);
        }
    }

    private static String bytesToHex(byte[] bytes){
        StringBuilder builder = new StringBuilder();
        for(byte b : bytes){
            builder.append(String.format("%02x", b));
        }
        return builder.toString();
    }
}

 위와 같이 SHA256 클래스를 static 메서드로 이루어진 유틸성 클래스로 설계한 이유는 다음과 같았다.

1. 스프링에서 제공하는 기능을 사용하지 않음

2. 상태 값이 없음

3. 멀티 쓰레드 환경에서 공유해도 안전함

4. 클라이언트에서 이를 사용하기 위한 추가작업(멤버필드 추가, 생성자 메서드 수정)이 필요없음

 이렇게 놓고보니 결국 싱글톤으로 관리되는 빈을 사용하지 않고 static 메서드 클래스를 사용하는 이유는 딱 하나. 4번 뿐이었다. 결국 내가 static을 선택한 이유는 클라이언트 입장에서의 코드 편의성 하나였던 것이었다.

 static에 대한 개발자들의 여러 의견들을 통해 static 사용을 지양하는 여러 이유를 찾을 수 있었다. 메모리의 메서드영역에 저장되어 GC 불가 및 메모리 문제를 야기할 수 있고, 확장이 불가하고, 상태 값 역할로 공유해서 사용할 경우 추론이 어렵고, 공유로 인한 문제가 발생할 수 있고 등등... 그 중 나의 프로젝트 구조에서 크게 와닿았던 문제가 바로 테스트가 까다롭다는 점이었다.

 최초 테스트 코드 작성 시 SHA256 클래스를 모킹 후 스터빙하기 위해 시도했으나 실패했다. 확인결과 새로운 의존 라이브러리를 사용하여 테스트 메서드마다 클래스를 Mocking, 스태틱 메서드를 stubbing해야 했고, 테스트가 끝나면 클래스의 Mocking을 해제해야했다. 배보다 배꼽이 더커진 느낌이 들어 클래스를 목킹하지 않고 SHA256 호출 부분에서 문제가 발생하지 않도록 요청이나 응답 테스트 픽스처들을 SHA256 클래스의 실제 동작에 맞게 신경써서 생성하게 되었다. 

 그 결과, 요청 픽스처가 변경되면 응답 픽스처도 변경해야했고, SHA256 클래스 내에서 문제가 발생하면 테스트가 실패하는 구조가 되었다. 테스트 메서드와 테스트 픽스처가 SHA256 클래스 실제 구현부에 강하게 결합되버린 것이다. 결과적으로 단위 테스트가 아니라 단위 + SHA256 테스트가 되버린 것...이다.

 만약 SHA256을 빈으로 등록했다면 쉽게 모킹, 스터빙이 가능했을 것이고, 테스트 메서드는 SHA256의 구현에 신경쓸 필요가 없으므로 단위 테스트의 목적에 맞게 구현됐을 것이다. 클라이언트 코드의 가독성도 떨어지지 않는다. 멤버필드 하나만 추가해주면 되기 때문이다. 빈으로 등록하는 것이 더 좋은 선택지였지 않았을까 하는 아쉬움이 남는다

Q3. 동일 ID 값을 가진 요청 데이터로 회원가입 요청이 빠르게 두번 연속으로 발생할 경우 동일한 ID로 회원가입이 될 것 같나요?

이것도 질문의 의도를 이해하지 못했다. 이 질문을 듣는 순간 머릿속이 아주 새 하얗게 변한게 생각난다. 면접관님께서는 동일 ID를 로그인에 사용될 ID로 말하고 있었지만, 나는 엔티티의 키로 사용하는 ID로 이해해버렸다.

 쓰기 락을 걸거나 기본키로 ID를 사용한다고 말했다.

# 또...돌아갈 수 있다면...

네 유저 ID가 키 값이 아니기 때문에 동일한 userId로 요청이 빠르게 중복되어 들어올 경우 테이블에 데이터가 중복되어 적재될 것 같습니다. userId를 유니크 키로 하거나, Id 컬럼을 없애고 userId를 PK로 사용해도 될 것 같습니다!

# 실제 테스트 및 회고

  실제 테스트를 해봤다. 그런데 이미 userId를 기본키로 해놨었다. 정신머가리가 빠졌다는 것을 다시한번 느꼈다. 어쨌든 동시성 테스트를 curl를 통해 진행하였다. 그 결과 첫번째 요청은 정상 수행됐으나 두번째 요청은 기본키 제약조건 위반으로 인해 런타임 예외가 발생하였다. 해당 예외에 대한 예외처리를 하지 않았기 때문에 '시스템에서 알수없는 에러가 발생하였습니다.'라는 문구가 클라이언트에게 응답되었다. 해당 예외에 대한 예외처리를 통해 적절한 메시지를 내려주면 좋았을 것 같다.

Q4. Spring Security에 적용하신 JsonAuthorizationFilter는 굳이 필요하다고 생각들지 않은데 사용한 이유가 있나요? 제가 생각했을 때는 UserDetails랑 UserDetailsService 추가해주면 될것같은데요?

A4. 어… 저는 필요하다고 생각합니다. 어쨌든간에 UsernamePasswordFilter에서는 폼 형식으로 온 요청에 대해 getParameter 메서드로 ID와 PW를 추출하고 있기 때문입니다. 로그인에서 Json 형식으로 올 경우 해당 필터가 값을 추출하지 못합니다.. 주저리 주저리.. 그래서 JsonAuthorizationFilter 클래스가 충분히 가치(갑자기 뭔 가치야 ㅁㅊ놈아..)있는 클래스라고 생각합니다.

# 또... 돌아갈 수 있다면...

JsonAuthorizationFilter 는 꼭 필요합니다. 말씀하신대로 UserDetails와 UserDetailsService를 추가하여 구현하는 방법도 있지만, 그 방법은 스프링 시큐리티 필터를 통해 인증을 처리할 때 유효합니다.

 spring security 설정을 건드리지 않고 UserDetailsService를 구현하여 인증 처리를 수행한다는 것은 security의 기본 설정에 UserDetailsService를 커스텀하여 적용하는 경우입니다. security 기본 설정은 formLogin 방식이고, 이는 곧 UsernamePasswordAuthenticationFilter가 추가된다는 뜻입니다.

 이 필터는 폼 방식으로 들어온 요청만을 필터링할 수 있으므로 Json 형식으로 들어오는 요청을 받아야한다면 이를 대신할 수 있는 커스텀 필터가 꼭 필요합니다. 저는 이 커스텀 필터로 JsonAuthorizationFilter를 사용한 것이기에 JsonAuthorizationFilter는 꼭 필요한 클래스라고 생각합니다.

Q5-1. CloseableHttpClient를 사용한 이유가 있나요?

나) 네 Connection Pool로 관리되어 Connection 생성으로 인한 오버헤드를 아낄... 주저리주저리…

면접관님) 흠.. 이거 말고 다른거 사용해보셨나요? restTemplate 같은거요. CloseableHttpClient는 요즘 잘 사용안하는것 같은데

나) 네 사용해봤습니다. (여기서부터 해탈했다. 질문에 대한 답변을 제대로 한게 없으니 내가 아는 지식에 대해 자신감을 갖지 못했기 때문이다.) 사실  이걸 사용한 이유는 실무 프로젝트 중 HttpClient 사용 시 주저리 주저리… 그때 이 CloseableHttpClient를 통해 잘 해결한 경험이 있기 때문에 활용하면 좋겠다 라고 판단했던것 같습니다. (왜 이딴식으로 대답했는지 모르겠다. 정말... CloseableHttpClient로 포스팅도 하고, 현업에서도 겪은 문제라 잘 아는데말이다... 이 상황을 벗어나고 싶었던걸가 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ...훌쩎)

# 또...또 돌아갈 수 있다면...

CloseableHttpClient는 커넥션 풀에서 커넥션을 관리할 수 있습니다. RestTemplate을 사용할 경우 HTTP 통신에 필요한 커넥션을 생성하고, 통신이 끝나면 해당 커넥션을 삭제하는 걸로 알고 있습니다. 하지만 CloseableHttpClient는 커넥션 풀에서 관리되는 커넥션에 대한 설정도 할 수 있는데 이를 통해 통신이 끝난 커넥션을 일정 시간동안 대기시켜 놓을 수 있습니다. 즉, 재사용이 가능하며 이는 곧 커넥션을 맺는 오버헤드를 감소시킬 수 있습니다.

 정리하면 커넥션 풀 및 커넥션 설정을 관리할 수 있고, 요청이 몰릴 경우 커넥션 생성으로 인한 오버헤드를 줄일 수 있어 성능상의 이점을 가져올 수 있기에 CloseableHttpClient을 사용하였습니다.

Q6. PrintWriter를 굳이 선택한 이유가 있나. (혼잣말이셨음)

이건 혼잣말로 말씀하신건데 생각해보지 않은 내용이었다. PrintWriter에 대해 찾아보고 도루마무를 해봤다.

# 진짜 마지막으로 돌아갈 수 있다면...

(면접관님의 혼잣말이 끝나시는 순간 자신감있게 일어서며) PrintWriter는 문자 텍스트를 응답할 때 사용하는데 accessToken은 문자 텍스트 형태이기 때문에 이를 사용했습니다. 하지만 범용성을 생각한다면 OutputStream을 사용하는 것이 더 좋은 선택지라고 생각이 드네요! 감사합니다!

...

...

...

...

...

자신의 생각을 말해야하는 자리이니만큼 컨디션 관리는 매우 중요했지만, 컨디션 관리를 너무 못했다. 너무 긴장한 탓인지 면접관님들의 질문에 큰 부담을 갖고 임한것도 문제였다. 면접관님들은 그냥 궁금해서 물어본건데 나는 모든 질문에 '이 코드에 뭔가 문제가 있어서 물어보는구나' 라는 생각을 깔고 임했기 때문이다. 그래서 질문을 받을수록 내가 알고 있는 것들이 잘못된걸까라는 의심을 하게 되고, 내 생각을 적극적으로 전달하지 못하게 되었다. 이 부분이 정말 후회되는 부분이다.

 누군가 면접은 경험이라고 했다. 면접이 끝나는 순간 이 말이 크게 와닿았다. 하지만 결코 후회뿐인 면접은 아니었다. 면접을 통해 내 생각을 다시 한번 정리할 수 있고, 평소라면 생각할 수 없었던 물음들에 대해 고민하게 된 좋은 경험이었다.

 너무 가고싶었던 기업인만큼 아쉬움이 크지만, 다음 면접에서는 이런 후회를 다시 겪지 않도록 자신감 있게 임할것이다. 화이팅!! 

개요

 배열과 리스트 모두 여러 값을 관리하게 위해 사용한다. 기능적으로 같은 역할을 하는 배열과 리스트는 어떤 차이점이 있고, 이 중 어떤 타입을 사용하는게 더 기능적으로 유용할까?

결론부터 말하면 리스트

결론부터 말하면 리스트를 사용해야 한다. 왜? 그걸 이해하기 위해서는 변성, 공변, 불공변(무공변), 소거, 실체화 타입, 실체화 불가 타입과 같은 개념들을 이해해야한다. 하나씩 이해하며 왜 리스트를 사용해야하는지 알아보자.

첫번째 차이. 변성

 리스트와 배열의 첫번째 차이는 변성이다. 변성이란 타입의 계층 관계에서 서로 다른 타입 간에 어떤 관계가 있는지 나타내는 개념이다. 변성은 크게 공변, 반공변, 불공변(== 무공변) 으로 나뉘며 배열과 리스트와 연관성이 있는 공변과, 불공변에 대해 알아보자.

배열은 공변 (共變)

 공변은 '함께 공(共)', '변할 변(變)' 이라는 한자어 그대로 '함께 변한다'는 뜻이다. 함께 변하는 주체는 바로 계층관계이다. 즉, 타입의 계층관계에 따라 배열의 계층관계도 함께 변하는 것이다. 예를들어 Sub 클래스가 Super 클래스의 하위 클래스라면 배열 Sub[]도 배열 Super[]의 하위 타입이 된다.

 공변과 불공변을 구분할 때 업 캐스팅이 가능한가의 여부로 판단하기도 하는데, 공변일 경우 계층 관계가 유지되니 다형성으로 인해 업 캐스팅이 가능하기 때문이다.

다형성
한 타입의 참조변수를 통해 여러 타입의 객체를 참조할 수 있도록 만든 것을 의미한다. 좀 더 구체적으로, 상위 클래스 타입의 참조 변수로 하위 클래스의 객체를 참조할 수 있도록 하는 성질이다.

 정리하면 배열은 공변성을 띄므로 계층관계를 갖고, 아래와 같이 업 캐스팅이 가능하다.

public class Super {
}

public class Sub extends Super {
}

public static void main(String[] args) {
	Super[] sup = new Sub[10];
}

리스트는 불공변

 리스트는 불공변성을 띈다. Super 클래스와 Sub 클래스가 계층관계에 있더라도 리스트의 계층관계가 함께 변하지 않는다. 예를들어 Sub가 Super의 하위 클래스라도 List<Sub>는 List<Super>의 하위 타입이 되지 않는다. 그저 다른 타입으로 인식한다.

List<Super> supList = new ArrayList<Sub>(); // 타입 불일치 관련 컴파일 에러가 발생한다.

공변은 컴파일 타임에 타입 에러를 발견하지 못할 수 있다.

Object[] objectArray = new Long[1];
objectArray[0] = "안녕하세요";

 이 코드에서 컴파일 에러는 발생하지 않는다. 배열의 공변성에 의해 Object 배열과 Long 배열은 계층 관계를 갖게 되고, 다형성에 의해 상위 클래스 타입 변수에서 하위 타입 인스턴스를 참조할 수 있기 때문이다. Object 타입의 objectArray가 String 타입 값을 참조할 수 있는것도 마찬가지이다.

 문법적으로는 문제가 없기 때문에 컴파일 오류는 발생하지 않으나 컴파일 시 업캐스팅했던 objectArray의 실제 타입이 Long 타입으로 바뀔 것이기 때문에 ArrayStoreException 가 발생한다는 경고가 나온다.

//----- 컴파일 전 (.java)
Object[] objectArray = new Long[1];

// 경고 : 타입 'java.lang.String'의 요소를 'java.lang.Long' 요소의 배열에 저장하면 'ArrayStoreException'이 발생합니다
objectArray[0] = "안녕하세요"; 

//----- 컴파일 후 (.class)
Long[] arrayOfLong = new Long[1];
arrayOfLong[0] = "안녕하세요";

 Long용 저장소에 String 값을 넣을 수 없는 건 당연하다. 다만 배열 사용시 그 실수를 런타임에야 알게 되지만, 리스트를 사용하면 컴파일타임에 알 수 있다. 이게 배열보다 리스트를 사용해야 하는 가장 큰 이유 중 하나이다.

List<Object> list = new ArrayList<Long>(); // 컴파일 에러가 발생한다.
list.add("안녕하세요");

두번째 차이. 실체화 / 실체화 불가 타입

 실체화 타입이란 컴파일 타임에 사용된 타입이 런타임에 소거되지 않는 타입이다. 실체화 불가 타입은 컴파일 타임에 사용된 타입이 런타임에 소거되는 타입이다.

 조금 더 정확히 말하면 실체화 불가 타입은 해당 타입을 컴파일 타임에만 사용하여 타입 문제가 있는지 확인하고, 최종적으로 생성된 class 파일에서는 타입을 포함시키지 않는 것이다. 즉, 런타임에는 타입이 없는 상태, 소거된 상태로 실행되게 된다.

소거
원소 타입을 컴파일 타임에만 검사하고 런타임에는 해당 타입 정보를 알 수 없는 것을 의미한다.

이 둘의 개념이 잘 이해가지 않는다면 소거와 실체의 의미를 생각해보자. 실체(reify)란 '실제적인 것으로 만든다'라는 뜻이다. 무엇인가 소거 되버린 것으로는 실제적인 것을 만들지 못한다는 맥락에서 '실체화 불가 타입', 소거가 되지 않는다면 실제적인 것을 만들 수 있으니 '실제화 타입'으로 이해해보자.

 그럼 런타임에 소거되는 타입은 뭘까? 바로 제네릭 타입이다. 제네릭을 사용하는 타입은 소거되어 런타임에 타입 정보를 알 수 없다. 아래 java 파일을 컴파일하면 타입 소거된 class 파일이 생성되는 것을 확인할 수 있다.

// 컴파일 전 (.java)
List<Integer> dice = List.of(1,2,3,4,5,6);
List<Integer> dices = new ArrayList<>();

// 컴파일 후 (.class)
List localList = List.of(Integer.valueOf(1), Integer.valueOf(2), Integer.valueOf(3), Integer.valueOf(4), Integer.valueOf(5), Integer.valueOf(6));
ArrayList localArrayList = new ArrayList();

 실체화라는 개념은 제네릭의 탄생과 연관이 있는 것 같다. 제네릭은 컴파일 타임에 타입 안전성을 확보하기 위해 Java 1.5 버전부터 등장했다. 그런데 제네릭이 등장하기 전 사용하던 Raw 타입과의 호환성을 유지해야 했기 때문에 제네릭 타입은 컴파일 시 타입 체크에만 사용한 후 소거하게 된것이고, 소거된 타입을 분리하기 위해 실체화 타입, 실체화 불가 타입이라는 개념이 등장한게 아닐까 싶다 (뇌피셜)

 int, double 과 같은 원시 타입, 일반 클래스 및 인터페이스 타입, Raw 타입, List<?> 와 Map<?,?>와 같은 비한정적 와일드카드 타입을 실체화 타입으로 구분하고, List<T>, List<String>, List<? extends Number> 등과 같은 제네릭 타입 매개변수를 갖는 타입을 실체화 불가 타입이라 한다. 즉, 배열은 실체화 타입, 리스트는 실체화 불가 타입이라는 차이점이 있다.

제네릭 배열을 만들지 못하는 이유

 이러한 주요 차이로 인해 배열과 제네릭은 잘 어우러지지 못한다. 배열은 제네릭 타입, 매개변수화 타입, 타입 매개변수로 사용할 수 없다. 결과적으로 제네릭 배열 생성이 허용되면 타입 안전성이 깨질 수 있다. 이는 런타임 시 ClassCastException이 발생하는 것을 막아주겠다는 제네릭 타입의 취지에 어긋나게 되는 것이다.

만약 제네릭 배열을 만들 수 있다고 가정한다면 어떤 상황에서 ClassCastException 런타임 예외가 발생하는지 알아보자.

제네릭 배열의 사고 예제

// 컴파일 에러가 발생하지 않는다고 가정하며 제네릭 배열을 선언한다.
List<String>[] stringLists = new ArrayList<String>[1];

// Integer 타입의 리스트를 생성한다
List<Integer> intList = List.of(42);

// objects 배열의 시작주소에 stringLists 배열의 시작주소를 할당. 배열은 공변이니 문제없음
Object[] objects = stringLists;

// objects 첫번째 원소에 intList를 저장한다.
objects[0] = intList;

// stringLists[0] 에는 intList 인스턴스가 저장되어 있으며,
// get 메서드를 통해 조회 및 자동 형변환 시 ClassCastException 발생함.
String s = stringLists[0].get(0);

 즉, 제네릭을 사용하더라도 런타임에 ClassCastException이 발생하여 타입 안전성을 보장하지 못하게 되는 것이다. 이런 이유로 제네릭 배열을 만들지 못하도록 컴파일 에러를 발생시킨 것이다.

코드 리팩토링하기 (Object[ ] > Generic[ ] > List 순)

 배열로 형변환할 때 형변환 경고가 뜨는 경우 대부분은 배열인 E[] 대신 List<E>을 사용하면 해결된다. 코드가 조금 복잡해지고 성능이 살짝 나빠질 수도 있지만, 타입 안전성과 상호운용성은 좋아진다.

public class Chooser {
    private final Object[] choiceArray;

    public Chooser(Collection choices){
        choiceArray = choices.toArray();
    }

    public Object choose(){
        Random rnd = ThreadLocalRandom.current();
        return choiceArray[rnd.nextInt(choiceArray.length)];
    }

    public static void main(String[] args) {
        List<Integer> dice = List.of(1,2,3,4,5,6);

        Chooser chooser = new Chooser(dice);

        Integer choose = (Integer) chooser.choose();
        System.out.println(choose);  
        // String choose1 = (String) chooser.choose(); 올바르지 않는 타입으로의 형변환 > 런타임 예외 발생
    }
}

위 코드는 choose 메서드를 호출할 때마다 반환된 Object를 원하는 타입으로 형변환해야한다. 만약 타입이 다르다면 런타임에 형변환 오류가 발생한다. 먼저 제네릭을 도입해 리팩토링하자.

배열에 Generic 적용하기

 형변환 코드를 제거하기 위해 제네릭을 사용했다. 클래스 내에서 사용될 타입 매개변수 T를 전달받고, 생성자 메서드에 T 타입 매개변수를 갖는 컬렉션 타입 인스턴스를 전달받도록 수정했다. 이로써 형변환 하는 코드를 굳이 넣어주지 않아도 되게 되었다.

public class Chooser<T> {
    private final T[] choiceArray;

    public Chooser(Collection<T> choices){
        choiceArray = (T[]) choices.toArray();
    }

    public T choose(){
        Random rnd = ThreadLocalRandom.current();
        return choiceArray[rnd.nextInt(choiceArray.length)];
    }
    
    public static void main(String[] args) {
        List<Integer> dice = List.of(1,2,3,4,5,6);

        Chooser<Integer> chooser = new Chooser<>(dice);
        Integer value = chooser.choose();
        System.out.println(value);
    }
}

 생성자에서 (T[ ]) 코드를 추가해 형변환하고 있다. 이유는 toArray() 메서드의 반환 타입이 Object[ ] 이기 때문이다. 그런데 (T[ ]) 를 추가한 부분에서 확인되지 않는 형변환 경고가 발생한다. 확인되지 않는 이유는 T가 무슨 타입인지 알 수 없으니 컴파일러는 이 형변환이 런타임에도 안전한지 보장할 수 없다는 메시지이다.

 안전하다고 확신이 든다면 @SuppressWarnings 어노테이션과 함께 주석을 달아줘도 되지만 배열 대신 리스트를 사용한다면 경고 자체를 제거할 수 있다.

배열을 List로 변경하기

멤버필드를 리스트로 수정하고, Chooser 생성자 메서드에서 ArrayList 의 생성자 메서드를 사용하여 멤버필드에 값을 넣고 있다. 리스트를 사용하였고, 컴파일 오류가 발생하지 않았으니 런타임 시 타입 안전성이 보장되게 되었다.

public class Chooser<T> {
    private final List<T> choiceList;

    public Chooser(Collection<T> choices){
        choiceList = new ArrayList<>(choices);
    }

    public T choose(){
        Random rnd = ThreadLocalRandom.current();
        return choiceList.get(rnd.nextInt(choiceList.size()));
    }
}

정리

 리스트는 컴파일 타입 에러를 잡아 런타임 시 타입 안전성을 확보할 수 있다는 이점이 있다. 배열과 제네릭을 사용하는 리스트에는 매우 다른 타입 규칙이 적용된다. 배열은 공변이고 실체화되는 반면, 리스트는 불공변이고 타입 정보가 소거된다. 그 결과 배열은 런타임에 타입 안전성을 확보할 수 없고. 리스트는 확보할 수 있다.

 성격이 다른 둘을 섞어 쓰기란 쉽지 않다. 만약 둘을 섞어 쓰다가 컴파일 오류나 경고를 만나면, 가장 먼저 배열을 리스트로 대체하는 방법을 적용해야한다.

참고

 이펙티브 자바 - 조슈아 블로크

개요

 Controller 클래스에 대한 테스트 코드 작성 시 @WebMvcTest 어노테이션을 사용하여 웹 레이어에 대한 단위 테스트를 한다. 웹 레이어만 테스트하므로 JPA 관련 빈을 사용할 일이 없으며, Mock 객체를 등록할 필요도 없었다. 하지만 테스트 코드를 실행하니 japMappingContext 빈을 생성하지 못했다는 런타임 예외가 발생했다.

예외 내용 일부
Error creating bean with name 'jpaAuditingHandler': Cannot resolve reference to bean 'jpaMappingContext' while setting constructor argument
...
Caused by: java.lang.IllegalArgumentException: JPA metamodel must not be empty

 이에 대한 해결책으로 아래와 같이 JpaMetamodelMappingContext 클래스를 Mock Bean으로 등록하면 된다고 하지만, 왜 굳이 사용하지도 않고, 테스트하지도 않는 Jpa 관련 클래스를 모킹하는지 이해가 되지 않았다. 삽질을 하는 절차를 밟아보도록 하자. @_@

@WebMvcTest(NameController.class)
@MockBean(JpaMetamodelMappingContext.class) // 간단한 해결책
class NameControllerTest {
	...
}

JpaMetamodelMappingContext 란?

JpaMetamodelMappingContext란?
 Spring Data JPA의 일부로서, 엔티티에 대한 매핑 정보를 제공하는 역할을 하는 하는 클래스. 즉, Spring 에서 JPA 엔티티의 메타데이터를 필요로 할때 해당 메타데이터를 제공해준다.

JpaMetamodelMappingContext 빈은 어디서 등록되나?

 디버깅을 통해 확인한 결과 DefaultListableBeanFactory 클래스의 beanDefinitionNames 필드에 JpaMetamodelMappingContext 에 대한 클래스 정보가 들어가는 있는 것을 확인했다. 테스트 실행 시 먼저 등록해야할 빈의 클래스 정보를 먼저 수집한 후 beanDefinitionNames 에 넣고있었다. 즉, 어떤 이유로 인해 JpaMetamodelMappingContext가 생성되어야할 빈 리스트로 포함된것이다.

 해당 작업이 끝나면 아래와 같이 beanDefinitionNames 에 들어있던 클래스 정보를 하나씩 읽어 빈을 생성하게 된다.

 그리고 이 메서드의 하단부에 아래와 같이 beanFactory에서 getBean을 통해 jpaMappingContext 에 대한 빈을 생성/조회 를 시도한다. 이때 예외가 발생하는데 내부적으로 JpaMetamodelMappingContext 빈을 생성 실패하면서 발생하게 된다.

 이 빈에 대한 생성자를 보면 메서드의 models 값이 빈값으로 들어와 Assert 구문에 의해 JPA metamodel must not empty라는 예외가 발생하는 것을 알 수 있다.

어찌됐든  jpaMappingContext 가 어떤 이유로 인해 빈 등록을 시도하고 있고, 이를 찾아낸다면 이 에러의 원인도 해결할 수 있게 되었다.

DefaultListableBeanFactory 클래스가 뭐야

DefaultListableBeanFactory  클래스는 빈 팩터리 클래스 중 하나이며, 코드레벨에서 빈을 수동으로 등록할 때 이 클래스를 사용하여 빈 정보를 주입하기도 한다. 즉, 일반적인 빈 팩터리 클래스이다.

누가 JpaMappingContext 빈을 추가했나?

 그럼 이 클래스를 어떤 클래스가 빈으로 추가하려 했는지 알아보기 위해 다시한번 디버깅의 늪으로 들어갔다. 그리고 이 문제의 원인을 찾았다. 바로 Application 클래스가 문제였다. 테스트 코드 실행 시 Application 클래스의 정보를 로드하면서 @EnableJpaAuditing 어노테이션이 동작하게 된 것이다. 그리고 이 어노테이션의 설정 정보로 인해 japMappingContext 빈을 등록하려 했던 것이다.

 이 어노테이션은 설정 클래스로 JpaAuditingRegistrar.class를 로드하고 있는데 이 클래스는 ImportBeanDefinitionRegistrar의 구현체 클래스이다. 어플리케이션이 로드되면 구현체 클래스의 registerBeanDefinitions 메서드가 호출되는데, 바로 이때 jpaMappingContext 빈 정보를 등록하고, 뒤이어 auditingHandler 빈 정보도 등록한다.

(특이하게도 auditingHandler 라는 빈 핸들러를 추가할 때 빈 이름은 getAuditingHandlerBeanName(), 클래스는 null 로 등록하고 있는데 이 메서드의 반환 값이 바로 jpaAuditingHandler 였다.)

 결론은 @EnableJpaAuditing 에 의해 jpaMappingContext 빈 생성 정보가 빈 팩토리로 들어갔다는 것이다.

테스트를 실행하는데 왜 Application 클래스의 정보를 읽는거야?

 @WebMvcTest 를 사용하면 내부 동작에 의해 먼저 Application 클래스의 설정을 로드하고, 웹 레이어에 필요한 클래스를 스캔한다. 때문이다. 실제로 이 클래스에 있는 @EnableJpaAuditing 어노테이션을 제거하니 테스트코드에서 오류는 발생하지 않았다.

결론

  JPA 관련 예외가 발생한 이유는 Application 클래스에서 사용하고 있던 @EnableJpaAuditing 에 의해 jpaMappingContext 빈 생성 정보를 빈 팩토리가 로드했기 때문이었다. 이로 인해 테스트 코드에서 빈 생성을 시도하게 되고 필요한 JPA 설정들은 추가하지 않은 상태에서 필요한 JpaMetamodelMappingContext 빈을 생성하지 못해 발생했다. 

 JpaMetamodelMappingContext 를 MockBean으로 등록하면 문제가 해결됐던 것도 이해가 갔다.

 만약 누군가 이러한 에러를 마주하게 된다면 테스트 코드 어딘가에 JPA 관련 설정이 있는지와 Application 클래스에 관련 어노테이션이 있는지를 꼭 하길 바란다.

개요

 제네릭을 사용하면 많은 비검사 경고들을 마주한다. 필자의 경우 이러한 경고들은 IDE의 도움을 받아 수정했으며, 수정 자체에 큰 의의를 두진 않았다. 하지만 이러한 경고를 제거하는 것만으로 그 코드는 ClassCaseException이 발생할 일이 없는 타입 안전성을 보장하는 코드가 된다고 한다. 이제 비검사 경고를 제거하는 올바른 방법을 알아보자.

컴파일러의 도움을 받아 제거하라

 대부분의 경고는 컴파일러가 알려준 대로 수정하면 사라진다.

Set<Coin> coinSet = new HashSet();

 위 코드는 '매개변수화된 클래스 HashSet을 원시사용 했다.' 라는 경고가 발생한다. 매개변수화된 클래스는 제네릭 클래스를 나타낸다. 즉, 제네릭 클래스인데 타입 매개변수를 사용하지 않았다는 경고이다.

Set<Coin> coinSet = new HashSet<Coin>();
Set<Coin> coinSet = new HashSet<>(); // 컴파일러의 추론 기능 활용

 위와 같이 타입 매개변수를 명시하여 경고를 해결할 수도 있지만 다이아몬드 연산자(<>) 만으로 해결할 수 있다. 컴파일러가 올바른 실제 타입 매개변수를 추론해주기 때문이다.

경고를 제거할 수 없지만 타입 안전함이 확신된다면 경고를 숨겨라

 타입 관련 경고를 제거하려면 @SuppressWarnings("unchecked") 어노테이션 사용하면 된다. 이 어노테이션은 개별 지역변수 선언부터 클래스 전체까지 어떤 선언에도 달 수 있지만 가능한한 좁은 범위에 적용해야 한다. 보통 변수 선언, 아주 짧은 메서드, 생성자에 사용되며, 절대 클래스 전체에 적용해서는 안된다.

아래는 ArrayList의 toArray 메서드이다.

public <T> T[] toArray(T[] a) {
    if (a.length < size)
        // Make a new array of a's runtime type, but my contents:
        return (T[]) Arrays.copyOf(elementData, size, a.getClass());
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

 이 중 아래 코드에서 '확인되지 않는 형변환' 경고가 발생한다.

return (T[]) Arrays.copyOf(elementData, size, a.getClass());

return 문에는 해당 어노테이션을 적용할 수 없으므로, 아래와 같이 변수를 선언하고 어노테이션을 적용해준다. 또한 경고를 무시해도 되는 안전한 이유를 항상 주석으로 남겨둔다.

public <T> T[] toArray(T[] a) {
    if (a.length < size) {
        
        // 생성한 배열과 매개변수로 받은 배열의 타입이 모두 T[]로 같으므로 올바른 형변환이다.
        @SuppressWarnings("unchecked")
        T[] result = (T[]) Arrays.copyOf(elementData, size, a.getClass());
        return result;
    }
    System.arraycopy(elementData, 0, a, 0, size);
    if (a.length > size)
        a[size] = null;
    return a;
}

SuppressWarnings 옵션

정리

 비검사 경고는 중요하니 무시하지 말자. 모든 비검사 경고는 런타임에 ClassCastException을 일으킬 수 있다. 경고를 없앨 방법을 찾지 못했다면, 그 코드가 타입 안전함을 증명하고 가능한 한 범위를 좁혀 @SuppressWarnings("unchecked") 어노테이션으로 경고를 숨기자. 그런 다음 경고를 숨긴 근거를 주석으로 남긴다.

개요

 OAuth2와 JWT를 사용하여 인증 정책을 수립했다. 그런데 문제가 발생했다. 인증이 필요한 API 요청 시 403 에러가 발생하는 것이다. 헤더에 JWT 토큰도 잘 들어가 있고, 토큰 값을 통해 생성한 인증객체도 Security Context Holder에 들어가 있으며, 인가 권한은 ROLE_USER 인데 말이다. 원인을 파악해보자.

Security Filter Chain 주요 필터

 원인을 찾기 전 현재 Security Filter의 구성이 어떻게 이루어져있는지 간단하게 정리해보았다.

1. OAuth2AuthorizationRequestRedirectFilter

 OAuth2AuthorizationRequestRedirectFilter에서는 yml 또는 properties에 설정한 값을 기반으로,  registrationId에 대한 OAuth2 인증 서버의 로그인 URI를 redirect 해준다.

 시큐리티 설정에 OAuth2 로그인 요청 URI는 아래와 같은 형식으로 정의해달라고 하는데, 그 이유가 바로 이 필터를 거치게 하려 함이다.

/oauth2/authorization/[registrationId]

2. OAuth2LoginAuthenticationFilter

OAuth2LoginAuthenticationFilter 에서 하는 일이 아주 많다.

 첫째, 로그인 성공 시 자신의 서버로 redirect 되는 authorization code를 받고,

 둘째,  authorization code 를 활용하여 OAuth2 인증 서버로 accessToken을 요청하고,

 셋째, accessToken을 활용하여 OAuth2 리소스 서버로 유저 정보를 요청한다.

 넷째, OAuth2UserService 구현체 인스턴스를 호출하며, 내부에서 Authentication 인스턴스를 생성한다.

 정리하면, OAuth2 인증을 받고, 인증 유저에 대한 정보를 획득한 후 인증 객체를 생성하는 역할이다.

참고로 인증이 성공하면 추후 AuthenticationSuccessHandler의 구현체 인스턴스를 호출하게 되는데 이때 JWT 토큰을 발급하며, 클라이언트는 이 값을 받아 헤더에 추가한다. (이건 필자의 인증 정책 중 하나이니 굳이 이해할 필요는 없다. JWT 를 발급한다는 것만 알면 된다.

3. JWT Filter

 헤더의 JWT 토큰 값을 추출 후 검증한다. 유효한 토큰일 경우 Authentication 객체를 생성하여 Security Context Holder 내에 저장한다.

로그인은 성공했으나, 인증된 자원에 대한 요청은 실패

 OAuth2 로그인은 성공하고 JWT 토큰도 잘 발급이 되고, 헤더로 유효한 JWT 토큰도 오는 걸 확인했으나, 인증이 필요한 API 요청에만 실패했다. SpringSecurity 설정에 인증 필터를 거치지 않도록 설정한 view/login, /error 등에 대해서는 403 에러가 발생하지 않는 점을 고려해봤을 때 시큐리티 필터에서 '인증' 관련 문제가 있음을 추정하게 되었다. 

public class SecurityConfig {

    private final UserRepository userRepository;

    private final JwtProvider jwtProvider;
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception{

        http
                .authorizeHttpRequests((authz -> authz
                        .requestMatchers("/api/**").hasRole("USER")
                        .anyRequest().authenticated())
                )
		...
        return http.build();
    }


    @Bean
    public WebSecurityCustomizer webSecurityCustomizer() {
        return (web) -> web.ignoring().requestMatchers("/view/login", "/error", "/error/*", "/img/**", "/favicon.ico");
    }
}

발견되지 않는 에러 로그

 일반적으로 예외가 발생하면 에러 로그가 콘솔에 출력될텐데, 에러 로그가 출력되지 않았다. 시큐리티 로그에 /error 경로에 대한 요청이 들어오는걸로 봐서 내부 어딘가에서 예외가 발생했고, /error 경로로 리다이렉트 된것 같은데, 에러 로그가 보이지 않아 근원지를 찾을 수 없었다.

루트 로그 레벨을 trace 로 변경

 /error 리다이렉트 원인이 되는 로그가 분명 찍었을 것이라 판단하고 루트 로그 레벨을 trace로 변경해보았다. 그리고 다시 실행을 하니 원인을 찾을 수 있었다. AuthrozationFilter에서 AccessDeniedException이 발생했고, 이로 인해 /error 경로로 리다이렉트 되고 있던 것이었다. 놀랍게도 로그 레벨은 TRACE 였다. 

AuthorizationFilter 예외 발생 원인 분석

 내부 소스를 확인해 보니 authrozationManager.check() 호출 후 얻은 AuthroziationDecision의 isGranted() 메서드의 호출 결과에 따라 Access Denied 예외가 발생함을 확인할 수 있었다. isGranted의 구현체 클래스를 따라가니 아래의 세 조건을 만족할 경우에만 true를 리턴하고 있었다.

  그런데 필자가 생성했던 Authentication 객체는... authenticated 값이 false 였던..것이었다.

아... 나 커스텀 Authentication 클래스 사용했었구나.

커스텀 Authentication 클래스 확인

 헐레벌떡 확인해보니 부모 클래스에 authenticated 값이 있었지만, 따로 설정해주지 않았고, 부모 생성자만 호출해서는 authenticated 값도 설정되지 않고 있었다. 그렇다. 따로 설정을 해줬어야 했다.

public class UserAuthenticationToken extends AbstractAuthenticationToken {

    private final Long principal;
    private final String credentials;


    public UserAuthenticationToken(Long userId, String email, Collection<? extends GrantedAuthority> authorities) {
        super(authorities);
        this.principal = userId;
        this.credentials = email;
    }

    @Override
    public String getCredentials() {
        return credentials;
    }

    @Override
    public Long getPrincipal() {
        return principal;
    }
}

 super.setAuthenticated(true) 코드를 넣어 authenticated 값을 true로 설정했다.

public UserAuthenticationToken(Long userId, String email, Collection<? extends GrantedAuthority> authorities) {
    super(authorities);
    super.setAuthenticated(true);
    this.principal = userId;
    this.credentials = email;
}

테스트

잘된다.   👷 (삽을 어디뒀더라...)

회고

 유저에 대한 '인가'를 하면 당연히 '인증'된 객체로 처리될 줄 알았으나, 안된다. 비록 삽질을 하긴 했지만 매우 건강한 삽질이 아니었나 싶다.

 Authentication 객체의 authenticated 값을 AuthorizationFilter 에서 확인한다는 것과 커스텀 Authentication 클래스를 사용할 때 권한을 인가할지라도 인증은 되지 않아 authenticated 값이 자동으로 설정되지 않는다는 것도 알게 되었다. 인증 객체의 부모 생성자 메서드를 좀더 자세히 확인했더라면, 이 문제는 발생하지 않았을 테지만 OAuth2 필터 복습도 하고, 인증 매커니즘에 대해 다시 한번 정리를 하게 된 건강한 삽질이었다!

개요

 이번 아이템에서도 생소한 용어인 '로 타입'이 등장했다. 로 타입이 뭐길래 사용하지 말라는 걸까?

로 타입

 제네릭 타입에서 타입 매개변수(괄호 < > 안에 들어가는 타입 값)를 사용하지 않았을 때의 타입을 말한다. List<E>의 로 타입은 List, ArrayList<E>의 로 타입은 ArrayList 이다.

List list = ... // 로 타입!

로 타입의 사용 예

 아래는 로 타입을 사용하는 예이다. 컴파일 시 오류가 발생하지 않으나, 런타임 시 타입 오류가 발생한다. Coin을 Money로 캐스팅하려하니 에러가 나는 건 당연하지만 중요한건 이 에러가 컴파일에는 발생하지 않는다는 점이다. 이런 케스팅 에러는 런타임보다 컴파일 타임에 발견되는 것이 좋다.

List list = new ArrayList();

Coin coin = new Coin();
list.add(coin); // 실수로 Coin 인스턴스를 추가하였다.

Money getCoin = (Money) list.get(0); // 런타임 시 ClassCastException이 발생한다.

컴파일 타임에 발견되는 캐스팅 에러

 타입 매개변수를 사용한다면 컴파일 타임에에 컴파일러가 오류를 캐치하게 된다. 그럼 변수 초기화 시 타입 매개변수를 사용하면 무조건 해당 변수는 타입 안전성을 갖게되는걸까? 그건 아니다.

List<Money> list = new ArrayList(); // 타입 매개변수 사용

Coin coin = new Coin();
list.add(coin); // 컴파일 에러 발생!

Money getCoin = list.get(0);

메서드 파라미터에 사용되는 로 타입

 앞에서 제공한 코드 중간에 unsafeAdd 메서드가 추가되었고, 로 타입으로 list 값을 받고 있다. 이때 list.add(o) 부분에서 과연 컴파일 또는 런타임 에러가 발생할까?

List<Money> list = new ArrayList();

Coin coin = new Coin();
unsafeAdd(list, coin);

Money getCoin = list.get(0);

...

public static void unsafeAdd(List list, Object o){
    list.add(o); // 예외가 발생할까요?
}

list 에 대한 타입 매개변수를 Money로 했으니 당연히 list.add(o) 부분에서 컴파일 예러가 발생한다고 생각할 수 있지만 그렇지 않다. 심지어 list.add(o) 시 런타임 예외도 발생하지 않는다. Coin 타입의 인스턴스가 Money 타입의 list에 잘 들어간다. 대신 list.get(0) 을 통해 값을 조회할 때 ClassCastException이 발생한다.

 list 변수의 타입 안전성이 unsafeAdd 메서드에 추가한 '로 타입' 매개변수에 의해 파괴되는 순간이다. 

로 타입을 사용하면 안되는 이유

 💡  제네릭 타입이 제공하는 타입 안정성과 표현력을 굳이 버리는 꼴이다.
제네릭 타입에서 공식적으로 발을 뺀 타입이다.

로 타입 완전 별로인데 그냥 자바 진영에서 제명하면 안돼?

 로 타입을 폐기할 수 없는 이유는 개발자들이 제네릭을 받아들이는데 오랜 시간이 걸렸고, 이미 '로 타입'으로 작성된 코드들이 너무 많았기 때문에, 그 코드와의 호환성을 위해 남겨두고 있는 것이라고 한다.

모든 타입을 허용하려면 로타입 말고 Object 타입으로 사용하자

 모든 타입을 허용하는 변수를 정의할때는 정해진 타입이 없으니 로 타입으로 쓸 수 있지만, 제네릭 타입에서 발을 뺀 로 타입을 쓰는 것 자체가 모순이다. 이때는 로 타입 대신 Object 타입을 사용하자.

Coin coin = new Coin();
Money money = new Money();

List<Object> list = new ArrayList<>(); // 로 타입 대신 Object 타입
list.add(coin);
list.add(money);

Coin getCoin = (Coin) list.get(0);
Money getMoney = (Money) list.get(1);

메서드 파라미터는 타입 매개변수를 Object 타입으로 만들 수 없다.

 모든 타입을 허용하는 메서드를 만들고, 여러 타입 매개변수를 가진 리스트에서 이를 재사용하도록 만들 수 있을까? 실제로 Object 타입을 가진 list를 매개변수로 받는 add 메서드를 구현했더니 컴파일 에러가 발생한다. 컴파일 에러가 발생하는 이유는 List<Object> 타입과 List<Coin> 타입이 다르기 때문이다.

List<Money> list = new ArrayList<>();

Coin coin = new Coin();
objectAdd(list, coin); // 컴파일 에러

Coin getCoin = (Coin) list.get(0); // 컴파일 에러


...

public static void objectAdd(List<Object> list, Object o){
    list.add(o);
}

비한정 와일드카드 타입 활용

 컴파일 에러를 해결하기 위해 비한정 와일드카드 타입을 쓸 수도 있다. 하지만 와일드 카드를 사용할 경우 타입 안전성을 지키기 위해 null 외에 아무 값도 넣지 못하게 된다. 즉, 타입 안전성을 훼손하는 모든 작업은 할 수 없는 것이다. 단, get과 같은 작업은 타입 안전성을 훼손하지 않으므로 가능하다.

List<Money> list = new ArrayList<>();

Coin coin = new Coin();

objectAdd(list, coin);

...

public static void objectAdd(List<?> list, Object o){

    list.add(o); // 컴파일 에러
    list.get(0); // 컴파일 에러는 발생하지 않음.
}

 만약 모든 타입에 대해 타입 안전성을 훼손하지 않는 비지니스 로직을 처리해야할 경우 비한정 와일드카드 타입을 활용하겠지만, 그게 아니라면 굳이 모든 타입을 허용하는 메서드를 만들 필요는 없다고 생각한다.

로 타입을 사용하는 예외 상황

 로 타입을 사용해야 하는 상황도 있다.

1. class 리터럴

 class 타입이 들어가야하는 자바 문법에 List.class 와 같은 로 타입은 허용하지만, List<String>.class와 같은 매개변수화 타입은 허용하지 않는다.

2. instanceof 연산자

 instanceof 연산자는 비한정적 와일드카드 타입과 로 타입 말고는 적용할 수 없다.

정리

 로 타입을 사용하면 런 타임에 예외가 일어날 수 있으니 사용하면 안된다. 로 타입은 제네릭 도입에 따른 호환성을 위해 제공될 뿐이다.

개요

 '태그달린 클래스'라는 단어가 되게 생소하다. 이에 대한 의미를 이해하고, 이 클래스가 과연 어떤 단점을 갖길래 계층구조로 리팩토링 하라는지도 이해해보자.

태그달린 클래스란?

 태그달린 클래스란 멤버 필드와 관련있다. 멤버 필드가 클래스의 유형을 나타내는 경우 해당 멤버 필드를 태그 필드라고 한다. 그리고 태그 필드를 갖는 클래스를 태그달린 클래스라고 한다.

태그 달린 클래스의 예

 Figure 클래스는 shape 필드가 이 클래스의 유형을 나타낸다. 즉, 태그 필드이다. 유형마다 생성자가 따로 존재하며, area 메서드의 동작도 달라지는 것을 볼 수 있다. 이러한 클래스의 단점을 하나씩 짚어보자.

public class Figure {
    enum Shape { RECTANGLE, CIRCLE };

    // 태그 필드 - 현재 모양을 나타낸다.
    final Shape shape;

    // 다음 필드들은 모양이 사각형(RECTANGLE)일 때만 쓰인다.
    double length;
    double width;

    // 다음 필드는 모양이 원(CIRCLE)일 때만 쓰인다.
    double radius;

    // 원 생성자
    Figure(double radius){
        shape = Shape.CIRCLE;
        this.radius = radius;
    }

    Figure(double length, double width){
        shape = Shape.RECTANGLE;
        this.length = length;
        this.width = width;
    }

    double area(){
        switch (shape){
            case RECTANGLE:
                return length * width;
            case CIRCLE:
                return Math.PI * (radius * radius);
            default:
                throw new AssertionError(shape);
        }
    }
}

태그달린 클래스의 단점

1. 쓸데없는 코드가 많다

 열거 타입 선언, 태그 필드, switch 등 쓸데없는 코드가 많다. 이런 코드가 많은 이유는 이 클래스로 생성되는 인스턴스가 여러 유형(태그)을 가질 수 있기 때문이다.

2. 가독성 저하

 한 클래스에 여러 유형에 대한 로직이 혼합돼어 있어 가독성이 저하된다.

3. 불필요한 초기화가 늘어난다.

 멤버 필드의 불변성을 명시하기 위해 필드를 final로 선언한다. 위와 같은 코드는 필드를 final로 선언하려면 해당 태그에 쓰이지 않는 필드들도 생성자에서 초기화해야한다. 불필요한 초기화 코드가 늘어나는 것이다.

4. 태그 추가 시 클래스 전체를 수정해야한다.

 또 다른 의미의 태그를 추가하려면 클래스 전체를 수정해야한다. 예를들어 삼각형이 추가될 경우 이에 대한 생성자가 추가되어야하고, area() 메서드도 수정이 되어야 한다.

5. 인스턴스 타입만으로는 어떤 태그인지 알 수 없다.

 Figure 이라는 타입만으로 이 태그가 원인지, 사각형인지 알 수 없다.

태그 달린 클래스는 장황하고, 오류를 내기 쉽고, 비효율적이다.
태그 달린 클래스는 클래스 계층구조를 어설프게 흉내낸 아류일 뿐이다. - 책에서

클래스 계층 구조로 변환하기

 많은 단점을 갖는 태그달린 클래스를 계층 구조로 리팩토링 해보자. 리팩토링이 끝나면 기존 단점들을 얼마나 극복했는지도 확인해보자. 가장 먼저 계층구조의 루트가 될 추상 클래스를 정의해야한다.

1. 추상 메서드 선언

 태그 값에 따라 동작이 달라지는 메서드를 추상 메서드로 선언해야한다. 그리고 각각의 하위 클래스에서 이 동작을 정의하도록 한다. area 메서드가 이에 해당한다.

2. 일반 메서드 선언

 태그 값에 상관 없이 동작이 일정한 메서드들을 추상 클래스의 일반 메서드로 추가한다. Figure 클래스에는 이러한 메서드가 없기 때문에 넘어간다.

3. 멤버 필드 선언

 모든 하위 클래스에서 공통으로 사용하는 필드들을 전부 추상 클래스의 필드에 추가한다. Figure 클래스에는 이러한 필드가 없기 때문에 넘어간다.

이를 토대로 추상 클래스를 작성하면 아래와 같다.

abstract class Figure {
    abstract double area();
}

4. 구체 클래스 설계

 이제 추상 클래스를 확장한 구체 클래스를 설계한다. Figure의 태그는 원(Circle)와 사각형(Rectangle)이 있으므로 이를 클래스로 분리한다. 이로써 계층구조로의 리팩토링이 끝났다. 이제 기존 단점들을 극복했는지 확인해보자.

public class Circle extends Figure{

    private final double radius;
    
    public Circle(double radius){
        this.radius = radius;
    }
    
    @Override
    double area() {
        return Math.PI * (radius * radius);
    }
}

public class Rectangle extends Figure{

    private final double length;
    private final double width;

    public Rectangle(double length, double width){
        this.length = length;
        this.width = width;
    }

    @Override
    double area() {
        return length * width;
    }
}

단점을 모두 날려버린 계층구조

1. 쓸데없는 코드가 많다

 > 열거 타입 선언, 태그 필드, switch 등 쓸데없는 코드가 모두 없어졌다.

2. 가독성 저하

 > 다른 유형의 로직이 혼합되어 있지 않다. 클래스는 자신에 대한 로직만을 관리하고 있다.

3. 불필요한 초기화가 늘어난다

 > 사용하지 않아 불필요하게 초기화 해야했던 필드들이 모두 없어졌다.

4. 태그 추가 시 클래스 전체를 수정해야한다

 > 이제 태그 추가가 아닌 클래스 추가로 변경되었다. 만약 삼각형이라는 클래스가 추가되어도 기존 클래스의 수정은 필요 없게 되었다.

5. 인스턴스 타입만으로는 어떤 태그인지 알 수 없다

 > 타입만으로도 원인지, 사각형인지 알 수 있다.

태그 필드가 있다면 무조건 계층구조로?

그럼 태그 필드가 있는 클래스는 모두 계층구조로 바꿔야할까? 그건 아닌것 같다. 분리될 태그들이 상위 클래스와 is-a 관계일 때만 효용성을 가진다고 생각하기 때문이다. 물론 이런 관계를 갖지 않았다면 애초에 태그 필드를 도입하지 않았을 확률이 높지만, 코드에는 정답이 없고 사람이 짜는 것이니 기존 클래스의 구조를 분석한 후 계층 구조로 리팩토링 하는 것이 바람직하다고 생각한다.

정리

 태그 달린 클래스를 써야 하는 상황은 거의 없다. 만약 태그 필드가 있다면 이를 없애고 계층 구조로 리팩터링 하는 것을 고려해야 한다.

개요

 이번 아이템에서는 상속을 고려한 클래스인 상속용 클래스를 설계할 때 주의할 점에 대해 언급하고 있다. 내용을 읽어보니 이 아이템은 '상속을 고려해 설계하고 문서화하라' 보다는 '상속을 고려해 설계했다면 문서화하라' 라는 제목으로 와닿는 것 같다.

 그럼 상속용 클래스는 왜 문서화를 해야하고, 그러지 않았다면 상속을 금지해야하는지 알아보자.

상속이란?

상속(inheritance)이란 기존의 클래스에 기능을 추가하거나 재정의하여 새로운 클래스를 정의하는 것을 의미합니다.
이러한 상속은 캡슐화, 추상화와 더불어 객체 지향 프로그래밍을 구성하는 중요한 특징 중 하나입니다.
출처 : TCP School

 먼저 상속의 개념에 대해 한번 다시 짚어보자. 중요한 부분은 '재정의' 이다. 메서드를 재정의할 수 있다는 특성은 잠재적인 문제를 낳는다. 어디선가 자기 사용(self-use)중인 메서드를 재정의 할 수 있기 때문이다. 단순한 예를 들어보겠다.

상속을 통한 자기 사용 메서드 재정의

public class MyAdd {

    public int add(int a, int b){
        return a + b;
    }

    public int addAll(int... values){
        int result = 0;

        for(int value : values){
            result = add(result, value);
        }
        return result;
    }
}

 위 클래스에 add, addAll 메서드가 정의되어 있다. 여기서 만약 add 메서드만 재정의하여 사용하고 싶다면  새로운 클래스에서 이를 상속받은 후 아래와 같이 재정의 할 수 있다.

간단하게 더한 값에 2를 곱하도록 재정의 하였다.

public class OverrideAdd extends MyAdd {

    @Override
    public int add(int a, int b) {
        return (a+b)*2;
    }
}

  add 메서드를 재정의 한 후, add 메서드를 실행하였다. 2+2를 하고 더블로 한 8이 조회된다. 그런데 손댄 적 없는 addAll 메서드에서 2,2,3,3의 결과값이 10이 아닌 66이 조회된다. 이상하다.

class Main{

    public static void main(String[] args) {
        MyAdd overrideAdd = new OverrideAdd();

        int result = overrideAdd.add(2,2);
        System.out.println(result);  // 8

		...
        
        int result2 = overrideAdd.addAll(2,2,3,3); 
        System.out.println(result2); // 66?!
    }
}

 원인은 addAll 메서드에서 자신의 add 메서드를 사용(self-use)하고 있었고, 재정의된 add 메서드에 의해 의도하지 값이 조회된 것이다. 상속을 통한 자기사용 메서드를 재정의했더니 생각지 못한 곳에서 오류가 발생한 것이다.

public class MyAdd {

    public int add(int a, int b){
        return a + b;
    }

    public int addAll(int... values){
        int result = 0;

        for(int value : values){
            result = add(result, value); // self-use
        }
        return result;
    }
}

내부 동작을 설명해야 하는 상속용 클래스

 만약 addAll 메서드에 아래와 같은 주석을 추가했다면 어땠을까? 

모든 가변인자를 더합니다.
하지만 매우매우매우 중요한 내용이 있습니다. 각 가변인자를 더할 때 add 메서드를 사용한다는 것입니다!
만약 add 메서드를 재정의한다면 이 메서드도 영향을 받게 되니 주의하세요!

 이런 주석이 있었다면 addAll 메서드를 사용하는 시점에 이러한 사실을 알았을테니 add 메서드를 재정의하지 않거나, 다른 방법을 사용하여 변경 로직을 적용했을 것이다. 즉, 자기 사용(Self-use)을 하는 메서드에 대해서는 문서화를 통해 이러한 내부 구현을 알림으로써, 다른 개발자가 이를 인지할 수 있도록 해야한다.

문서화 시 포함되어야 할 내용들

1. 호출되는 재정의 가능한 자기사용 메서드 이름
2. 호출되는 순서
3. 호출 결과에 따른 영향도
4. 재정의 시 발생할 수 있는 모든 상황

 문서화 시 포함되어야 할 내용들은 위와 같다. 항목을 보면 알 수 있듯이 결국 '내부 구현'을 설명해야 한다. 내부 구현에 대한 내용은 @implSpec 어노테이션 사용하여 기재한다. 자바독에서 이 어노테이션을 인식하여 자동으로 내부 구현을 설명하는 Implementation Requirements 항목에 기재한 내용을 포함시켜 문서를 생성해줄것이다.

문서화 하기(feat. javadoc)

1. 주석 추가하기

MyAdd 클래스에 다음과 같이 주석을 추가한다. addAll의 경우 @ImplSpec을 통해 내부 구현을 기재하였다.

public class MyAdd {

    /**
     * 두 인자를 더합니다.
     * @param a 첫번째 인자
     * @param b 두번째 인자
     * @return 두 인자의 합
     */
    public int add(int a, int b){
        return a + b;
    }


    /**
     * 모든 가변인자를 더합니다.
     * @param values int 형 가변인자
     * @return 모든 가변인자의 합
     * @implSpec 각 가변인자를 더할 때 add 메서드를 사용합니다. 만약 add 메서드를 재정의한다면 이 메서드도 영향을 받게 됩니다.
     */
    public int addAll(int... values){
        int result = 0;

        for(int value : values){
            result = add(result, value);
        }
        return result;
    }
}

2. javadoc 문서 만들기 (intellij 기준)

[도구 > JavaDoc 생성] 을 선택하여 javadoc 문서를 생성한다. JavaDoc 범위는 현재 파일로 하고, 명령줄 인수에 필요한 명령어들을 입력한 후 '생성' 버튼을 누른다.

※ unknown tag: implSpec 오류

 @implSpec 어노테이션은 기본적으로 활성화되어 있지 않다. 만약 unknown tag: implSpec 오류가 난다면 명령줄 인수에 이를 활성화하도록 아래 명령어를 추가해주자.  

-tag "implSpec:a:Implementation Requirements:"

※ 인코딩 관련 오류

 만약 인코딩 관련 오류가 난다면 아래 명령어를 추가해주자.

-encoding UTF-8 -docencoding UTF-8 -charset UTF-8

3. 문서 확인하기

 생성된 문서를 확인하자. @implSpec 에 기재한 내용이 Implementation Requirements 항목에 포함되어 있따면 내부 구현이 담긴 문서 생성 작업에 성공한 것이다. 만약 이 클래스를 사용하는 개발자가 이 문서를 한번이라도 본다면, add 메서드를 재정의 했을 때 발생할 수 있는 문제 상황에 대해 인지할 수 있을 것이다.

AbstractCollection 클래스에서 사용하고 있는 @implSpec 예

@implSpec를 어떻게 사용하고 있는지 AbstractCollection 클래스의 remove 메서드를 통해 확인해봤다.

/** 
* @implSpec
* This implementation iterates over the collection looking for the
* specified element. If it finds the element, it removes the element
* from the collection using the iterator's remove method.
* {@code UnsupportedOperationException} if the iterator returned by this
* collection's iterator method does not implement the {@code remove}
* method and this collection contains the specified object.
**/
public boolean remove(Object o)

번역
 이 메서드는 컬렉션을 순회하며 주어진 원소를 찾도록 구현되었다. 주어진 원소를 찾으면 반복자의 remove 메서드를 사용해 컬렉션에서 제거한다.
 주어진 원소를 찾으면 remove 메서드를 사용해 컬렉션에서 제거하지만, 이 컬렉션의 iterator 메서드가 반환한 반복자가 remove 메서드를 구현하지 않았다면 UnsupportedOperationException을 던진다.

AbstractCollection 클래스에서도 내부 구현을 @implSpec 을 통해 기재하고 있다. 설명에 따르면 iterator 메서드를 재정의하면 이 remove 메서드의 동작에 영향을 줌을 알 수 있다.

 하지만 단순 내부 메커니즘을 문서화 시키는 것만이 상속을 위한 설계의 전부는 아니다. 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅을 잘 선별하여 재정의하도록 할 수 있도록 하는 것도 중요하다.

AbstractList의 removeRange

/**
 * Removes from this list all of the elements whose index is between
 * {@code fromIndex}, inclusive, and {@code toIndex}, exclusive.
 * Shifts any succeeding elements to the left (reduces their index).
 * This call shortens the list by {@code (toIndex - fromIndex)} elements.
 * (If {@code toIndex==fromIndex}, this operation has no effect.)
 *
 * <p>This method is called by the {@code clear} operation on this list
 * and its subLists.  Overriding this method to take advantage of
 * the internals of the list implementation can <i>substantially</i>
 * improve the performance of the {@code clear} operation on this list
 * and its subLists.
 *
 * @implSpec
 * This implementation gets a list iterator positioned before
 * {@code fromIndex}, and repeatedly calls {@code ListIterator.next}
 * followed by {@code ListIterator.remove} until the entire range has
 * been removed.  <b>Note: if {@code ListIterator.remove} requires linear
 * time, this implementation requires quadratic time.</b>
 *
 * @param fromIndex index of first element to be removed
 * @param toIndex index after last element to be removed
 */
 
 protected void removeRange(int fromIndex, int toIndex){
 	...
 }

번역
fromIndex 부터 toIndex까지의 모든 원소를 리스트에서 제거한다.
... 중략
이 리스트 혹은 이 리스트의 부분리스트에 정의된 clear 연산이 이 메서드를 호출한다. 리스트 구현의 내부 구조를 활용하도록 이 메서드를 재정의하면 이 리스트와 부분리스트의 clear 성능을 크게 개선할 수 있다.
 @implSpec
 이 메서드는 fromIndex에서 시작하는 리스트 반복자를 얻어 모든 원소를 제거할 때까지 ListIterator.next와 ListIterator.remove를 반복 호출하도록 구현되었다. 주의 : ListIterator.remove 가 선형 시간이 걸리면 이 구현의 성능은 제곱에 비례한다.

 clear 메서드의 훅(hook)으로써의 역할을 하는 removeRange 메서드이다. 서브 클래스에서 접근할 수 있도록 protected 접근제어자로 설계되었다.

 clear의 성능을 크게 개선할 수 있다고 말하는 이유는 내부 구현을 담은 @ImplSpec 을 보면 알 수 있다. 리스트 반복자를 얻어 원소를 제거할 때까지 next()와 remove()를 반복 호출하는 것이 기본 내부 구현 로직이라고 언급하고 있다. 만약 이 로직을 ArrayList, LinkedList 등 구현체의 구조에 맞게 적절히 재정의한다면 처리 시간을 단축시킬 수 있고, 이를 hook으로 사용하는 모든 메서드, 즉 clear 메서드의 성능을 개선할 수 있다.

 List 구현체의 사용자는 removeRange 메서드에는 관심이 없음에도 불구하고 이에 대한 메서드와 내부 구현을 제공한 이유는 하위 클래스의 clear 메서드를 고성능으로 만들기 쉽게 하기 위함인 것이다. 즉, 서브 클래스의 구현 클래스에서 성능 개선이 가능한 부분이 있다면 이를 재정의하여 hook으로 활용할 수 있도록 protected 접근제어자를 가진 메서드로 설계해야 한다.

protected 메서드 설계의 기준

마법은 없다. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 '유일'하다.

 하지만 protected 메서드 설계에 대한 정해진 기준은 따로 없다고 한다. 책에서는 심사숙고해서 잘 예측해본 다음, 실제 하위 클래스를 만들어 시험해보는 것이 최선이라고 말하고 있다.

재정의 가능 메서드는 생성자에서 호출하면 안된다.

 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다. 아래와 같이 생성자에서 재정의 가능 메서드를 호출한다면, 이를 재정의했을 때 오작동을 일으킬 수 있다.

public class Super {

    // 생성자가 재정의 가능 메서드를 호출하는 잘못된 예
    public Super(){
        overrideMe();
    }

    public void overrideMe(){

    }
}

public class Sub extends Super {

    private final Instant instant;

    Sub(){
        instant = Instant.now();
    }

    @Override
    public void overrideMe(){
        System.out.println(instant);
    }

    public static void main(String[] args) {
        Sub sub = new Sub();
        sub.overrideMe();
    }
}

 sub.overrideMe() 메서드를 호출하면 instant를 두 번 출력하리라 기대하겠지만, 첫 번째는 null을 출력한다. 상위 클래스의 생성자는 하위 클래스의 생성자가 인스턴스 필드를 초기화하기 전에 overrideMe()를 호출하기 때문이다.

 만약 생성자에 메서드를 넣어야한다면 해당 메서드를 재정의하지 못하도록 private 접근 제어자를 사용하거나 final, static 타입으로 생성자를 설계하면 된다.

상속용 클래스는 족쇄가 되면 안된다.

 널리 쓰일 클래스를 상속용으로 설계한다면 문서화한 내용과, protected 메서드, 필드를 구현하면서 선택할 결정에 영원히 책임져야 한다. 그 클래스의 성능과 기능에 족쇄를 채울 수 있기 때문이다.

 처음 보여준 MyAdd 클래스의 경우 add 메서드를 재정의하면 addAll 메서드에 문제가 발생할 수 있기 때문에 함부로 수정할 수 없다. 기능에 대한 족쇄가 채워진 것이다.

상속용 클래스 말고 일반 클래스는?

 그럼 일반적은 구체 클래스는 어떨까? 상속용으로 설계된 클래스가 아니니 문서화도 되어있지 않고, 다른 클래스에서 상속도 가능하다. 이 클래스에 변경 사항이 생기게 되면 이를 상속받는 하위 클래스에서 문제가 발생하거나, 하위 클래스에서 재정의하여 사용할 경우 자기 호출로 인한 문제도 발생할 수 있다.

 이 문제를 해결하는 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다.

상속을 금지하는 방법

1. 클래스를 final 로 선언하기

 클래스를 final로 선언할 경우 해당 클래스를 다른 클래스에서 상속할 수 없다. 만약 MyAdd 클래스를 final로 선언한다면 다른 클래스에서 상속 시 컴파일 에러가 발생하게 된다.

2. 모든 생성자를 private로 선언하고 정적 팩터리 메서드로 만들기.

 상속 시 기본적으로 부모 클래스의 기본 생성자를 호출하게 된다. 기본 생성자를 호출하지 못하도록 private로 막고, 정적 펙터리 메서드를 통해 인스턴스를 제공하는 방법이다.

public class MyAdd {

    private MyAdd(){
        
    }
    
    public static MyAdd newInstance(){
        return new MyAdd();
    }

정리

 상속용 클래스를 설계하기란 결코 만만치 않다. 클래스 내부에서 사용되는 자기사용 패턴을 모두 문서로 남겨야 하고, 내부 구현에서는 이를 반드시 지켜야한다. removeRange처럼 다른 이가 효율 좋은 하위 클래스를 만들 수 있도록 일부 메서드를 protected로 제공해야 할 수도 있다. 하지만 이에 대한 기준은 없으며 설계자의 많은 고민과 테스트가 필요하다.

 그러니 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지시키도록 설계하는 것이 정신건강에 좋다.

오류를 내기 쉬운 상속

 상속은 코드 중복을 줄이고, 기능을 확장하는 강력한 수단이지만, 잘못 사용하면 오류를 내기 쉽기 때문에 주의를 요한다.

 HashSet이 처음 생성된 이후 원소가 몇개 더해졌는지(HashSet의 크기와는 다른 개념이다.) 를 확인하는 기능을 상속을 통해 추가해보았다.

잘못 사용된 상속

public class InstrumentedHashSet<E> extends HashSet<E> {

    private int addCount = 0;

    public InstrumentedHashSet(){

    }

    @Override
    public boolean add(E e){
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount(){
        return addCount;
    }
}

class Main{
    public static void main(String[] args) {
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
        s.addAll(Set.of("가","나","다"));

        System.out.println(s.getAddCount());
    }
}

 HashSet을 상속받는 InstrumentedHashSet 클래스를 생성한 후 추가된 원소의 수를 나타내는 addCount 멤버필드를 생성하고, HashSet 클래스에 원소를 추가하는 메서드를 재정의하여 addCount를 증가시키도록 구현하였다.

 겉으로 봐선 문제가 없어보이지만 실제로 main 메서드를 실행하면 getAddCount()은 예상했던 3이 아닌 6을 리턴한다.

6을 리턴하는 이유

HashSet에서 사용하는 addAll 메서드는 내부적으로 add 메서드를 호출하기 때문이다. 이 add 메서드는 addCount를 증가시키도록 재정의되었기 때문에 3이 아닌 6이 증가하는 것이다.

public boolean addAll(Collection<? extends E> c) {
    boolean modified = false;
    for (E e : c)
        if (add(e))
            modified = true;
    return modified;
}

상속을 유지하고 문제를 해결하는 방법

하나, addAll 메서드를 재정의하지 않는다.

addAll 메서드를 재정의하지 않으면 HashSet에 존재하는 addAll 메서드를 사용하게 된다. 이때에는 addCount 값을 증가시키지 않고, 재정의된 add 메서드를 호출할 때만 증가시키게되므로 당장은 제대로 동작하게 된다.

하지만 이는 HashSet의 addAll이 add 메서드를 이용해 구현했음을 가정한 해법이다. addAll의 내부 구현에 종속된 것이다. 이런 상황에서 HashSet의 addAll 메서드 내부 구현이 add 메서드를 호출하게 아닌 다른 방식으로 변경된다면 어떨까? 재정의한 add 메서드는 호출되지 않아 버그가 발생할 것이다.

 이처럼 상위 클래스의 내부 구현에 의존하는 메서드는 항상 잠재적인 위험요소가 된다.

public class InstrumentedHashSet<E> extends HashSet<E> {

    private int addCount = 0;

    public InstrumentedHashSet(){

    }

    @Override
    public boolean add(E e){
        addCount++;
        return super.add(e);
    }
    public int getAddCount(){
        return addCount;
    }
}

class Main{
    public static void main(String[] args) {
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
        s.addAll(Set.of("가","나","다"));

        System.out.println(s.getAddCount());
    }
}

둘, addAll 메서드를 다른 식으로 재정의한다.

 주어진 컬렉션을 순회하며 원소 하나당 add 메서드를 한번만 호출하는 것이다. 이 방식은 상위 클래스의 addAll 메서드를 호출하지 않으니 그 메서드의 내부 구현이 어떻게 동작하는지 신경쓸 필요가 없다.

 하지만 상위 클래스의 메서드 동작을 다시 구현하는 것은 단순 호출하는 것보다 많은 시간과 노력이 필요하다. 자칫 성능을 떨어뜨릴 수도 있다.

public class InstrumentedHashSet<E> extends HashSet<E> {

    private int addCount = 0;

    public InstrumentedHashSet(){

    }

    @Override
    public boolean add(E e){
        addCount++;
        return super.add(e);
    }

    public boolean addValues(Collection<? extends E> c) {
        for(E e : c){
            add(e);
        }
        return true;
    }

    public int getAddCount(){
        return addCount;
    }
}

class Main{
    public static void main(String[] args) {
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
        s.addValues(List.of("가","나","다"));

        System.out.println(s.getAddCount());
    }
}

캡슐화를 깨뜨리는 상속

 두번째 방법을 사용하면 문제가 해결되긴 하지만, 객체지향적인 문제가 발생하는데 바로 캡슐화가 무너지게 되는 것이다.

캡슐화
객체의 속성과 행위를 하나로 묶고, 실제 구현 내용 일부를 내부에 감추어 은닉한다.

 첫번째 방법의 경우 부모 클래스의 addAll 메서드를 호출했다. 이는 HashSet의 addAll 메서드가 내부적으로 add 메서드를 호출한다는 사실에 근거하였다는 점에서 캡슐화를 무너뜨린다.

두번째 방법은 어떨까? addAll 의 메서드를 호출하지도 않고 HashSet의 구현부를 꼭 알아야하는 부분도 당장은 없어보인다. 하지만 InstrumentedHashSet에 메서드를 추가할 때 HashSet의 메서드 시그니처를 알고 피해야한다는 점에서 캡슐화를 무너뜨린다.

 이를 반대로 생각하면 기존 자식 클래스에서 사용하는 메서드 시그니처와 똑같은 메서드가 부모 클래스에 새로 추가될 때 문제가 발생할 수 있다.

 아래 코드는 들어오는 정수 값에 대해서는 반드시 0 이상의 양수만 받을 수 있도록 하는 HashSet을 관리하기 위해 integerValidation 이라는 private 메서드를 추가한 상황이다.

 테스트를 해보면 -1 과 같은 값이 들어갈 경우 예외가 발생하게 된다. 

public class InstrumentedHashSet<E> extends HashSet<E> {

    private int addCount = 0;

    public InstrumentedHashSet(){

    }

    @Override
    public boolean add(E e){
        integerValidation(e);
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        for(E e : c){
            add(e);
        }
        return true;
    }

    public int getAddCount(){
        return addCount;
    }

    private void integerValidation(E e){

        if(Integer.class.isInstance(e)){
            Integer a = (Integer)e;

            if(a.intValue() < 0){
                throw new IllegalArgumentException("Integer 타입은 0 이상 값만 추가할 수 있습니다.");
            }
        }
    }
}

class Main{
    public static void main(String[] args) {
        InstrumentedHashSet<Integer> s = new InstrumentedHashSet<>();
        s.addAll(List.of(Integer.valueOf(0),Integer.valueOf(1),Integer.valueOf(-1))); // 예외발생

        System.out.println(s.getAddCount());
    }
}

 그런데 몇년 후 HashSet에 똑같은 메서드 시그니처를 갖고 반환만 다른 integerValidation이 추가된다면, 부모 클래스와 자식 클래스의 메서드가 충돌하게 되어 컴파일 에러가 발생하게 된다.

 결국 캡슐화가 무너지기 시작하면 결합도가 강해지게 되고, 강해진 결합도는 어떤 클래스의 변경이 일어났을 때 결합된 클래스에도 영향을 미치게 된다.

상속말고 컴포지션

 이러한 문제를 피해가는 방법이 바로 컴포지션이다.

컴포지션
다른객체의 인스턴스를 자신의 인스턴스 변수로 포함해서 메서드를 호출하는 기법.

위 상속을 컴포지션 방식으로 변경하면 아래와 같다.

 기존 인스턴스를 확장하는게 아닌 독립적인 InstrumentedHashSet 클래스를 만들고, private 필드로 기존 클래스의 인스턴스를 멤버필드로 추가하였다. 이 방식은 HashSet의 내부 구현을 새롭게 재정의할 필요가 없고, Set 타입 인스턴스를 외부로부터 주입받는다는 점에서 약한 결합도를 갖게 된다.

 또한 Set 인스턴스의 캡슐화도 무너뜨리지 않는다. 앞서 HashSet에 같은 시그니처를 갖는 메서드가 추가되도 이 클래스에는 아무런 영향을 끼치지 않는다.

public class InstrumentedHashSet<E> {

    private Set<E> set;
    private int addCount = 0;

    public InstrumentedHashSet(Set<E> set){
        this.set = set;
    }

    public boolean add(E e){
        addCount++;
        set.add(e);
        return true;
    }

    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        set.addAll(c);
        return true;
    }

    public int getAddCount(){
        return addCount;
    }
}

class Main{
    public static void main(String[] args) {
        Set set = new HashSet<String>();
        InstrumentedHashSet<String> s = new InstrumentedHashSet<>(set);
        s.addAll(Set.of("가","나","다"));
        System.out.println(s.getAddCount());
    }
}

그럼 상속은 언제써야해?

 상위 클래스와 하위 클래스와 관계가 정말 is-a 관계일 때만 사용해야한다. 예를들어 Dog과 Animal의 경우 Dog is Animal 이라는 관계가 성립한다. 하지만 이를 확신할 수 없다면 컴포지션을 사용하자.

이를 위반한 Properties와 Hashtable

 자바 라이브러리에서 이 원칙을 위반한 예시로 Properties가 있다. 이 클래스는 String 타입의 key, value를 관리하는 클래스로 Hashtable을 상속받고 있다.

 Properties에 값을 추가하려면 String 값만 받는 setProperty 메서드를 사용하면 된다.

public synchronized Object setProperty(String key, String value) {
    return put(key, value);
}

그런데 문제는 부모 클래스의 put 메서드를 사용할 경우 Object를 받을 수 있어 아무 타입의 값을 넣을 수 있다.

@Override
public synchronized Object put(Object key, Object value) {
    return map.put(key, value);
}

이 결과 Properties의 store 메서드와 같은 공개 API를 더이상 사용할 수 없다. 아래와 같이 object 타입의 값을 String 으로 변환하는 부분에서 Cast 예외가 발생하기 때문이다.

for (Map.Entry<Object, Object> e : entrySet()) {
    String key = (String)e.getKey();
    String val = (String)e.getValue();
    key = saveConvert(key, true, escUnicode);
    /* No need to escape embedded and trailing spaces for value, hence
     * pass false to flag.

정리

 상속은 강력하지만 캡슐화를 해친다는 문제가 있다. 상속은 상위 클래스와 하위 클래스가 is-a 관계일때만 사용해야 하지만 이를 확신할 수 없다면 컴포지션을 사용하자. 

참고

https://iyoungman.github.io/designpattern/Inheritance-and-Composition/ - 컴포지션

1. 개요

  웹 프락시 서버는 중개자이다. 클라이언트와 서버 사이에 위치하여 그들 사이의 HTTP 메시지를 정리하는 중개인 역할을 한다.

2. 중개인 역할

 웹 프락시 서버는 클라이언트 입장에서 트랜잭션을 수행하는 중개인 역할이다. 클라이언트로부터 HTTP 요청을 받은 후 클라이언트 대신 실 서버와 통신하기 때문이다.

3. 개인 프락시와 공용 프락시

3.1. 공용 프락시

 공용 프락시는 여러 사용자에게 공유된 프락시로 일반적인 프록시 하면 공용 프록시라고 생각하면 된다. 캐시 서버나 보안에 활용된다.

3.2. 개인 프락시

 개인 프락시는 특정 사용자나 그룹이 특정 목적을 위해 사용하는 프락시를 말한다. VPN에 활용된다.

4. 프락시 vs 게이트웨이

 프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하고, 게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결한다. 게이트웨이는 프로토콜 변환기의 역할까지 하는 것이다.

 하지만 실질적으로 프락시와 게이트웨이의 차이점은 모호하다. 브라우저와 서버는 다른 버전의 HTTP를 구현할 수 있기 때문에 때때로 약간의 프로토콜 변환을 할 수 있으며, 개인 프락시의 경우 SSL 보안 프로토콜을 지원하기 위해 게이트웨이의 기능을 구현하기 때문이다.

5. 프락시 사용 이유

 프락시 서버를 사용하면 보안 개선, 성능 향상, 비용 절약의 효과를 얻을 수 있다. 모든 HTTP 트래픽을 보고 요청을 핸들링할 수 있기 때문에 트래픽을 감시하고 수정할 수 있다.

 예를들어 성인 콘텐츠를 차단할 때 부적절한 사이트를 강제로 차단하거나, 서버의 리소스(ex 문서) 를 받아올 때 특정 클라이언트에게는 비밀번호를 요구하거나, 사본 리소스를 관리하여 리소스에 대한 접근 속도를 높여주는 웹 캐시 등으로 사용된다.