[Item21] 인터페이스 default method는 만능이 아니다

당연한 말이지만 인터페이스는 구현하는 쪽을 생각해 설계해야 하고 클래스는 사용하는 쪽을 생각해 설계해야 한다

코드를 작성한다는 것은 작게 보면 어떤 기술을 사용해 멋진 프로그램을 만들어내느냐 지만

크게 보면 결국 요구사항을 충족시키는 프로그램을 어떻게 만들어내느냐 이기 때문이다

클라이언트 혹은 액터라고 부르는 이해 관계자는 인터페이스나 클래스에 기대하는 행위가 있다

개발자는 그 기대에 부응할 의무가 있다

 

Java8부터 인터페이스에 default method를 추가할 수 있게 됐다, 이는 엄청난 축복이지만 저주가 될 수도 있다

위에서 말한 내용 때문인데 클라이언트는 인터페이스에 기대하는 행위가 있는데 

수많은 구현체들에서 이 기대가 올바르게 작동하리라는 보장이 없기 때문이다

책에서는 apache.commons.SynchronizedCollection의 예를 들었는데 Java8에서 추가된 default method 중

removeIf를 재정의하지 않아 SynchronizedCollection가 보장하기로 한 동기화가 올바르게 수행되지 않는다

 

자신이 직접 작성한 인터페이스라면 수정이 쉽겠지만 외부의 라이브러리를 사용할 때 문제가 된다

자바가 관리하는 라이브러리면 이런 문제가 있더라도 금방 수정될 것이다

third-party를 사용하게 되면 업데이트가 느리거나 되지 않을 수도 있다, 가능하면 표준 라이브러리를 사용하도록 하자

그래서 난 웬만하면 apache.commons, guava 같은 것에 의존하지 않으려고 하는데

쓰다 보면 수많은 Util Class 덕분에 생산성 차이가 나니 apache.commons 정도는 사용한다

 

변경하려는 인터페이스가 여러 구현체를 갖고 있다면, 특히나 동시성과 관련한 구현체들이 있다면 더욱 주의해야 한다

아직 동시성 근처에도 못 가봐서 자세히 설명할 순 없지만 순차적 방식과 다르게 미묘한 문제를 뿜어내기도 한다

따라서 프로젝트에 변경이 필요하다 하여 최상위 인터페이스에 default 메서드를 박아버리지 말고

SynchronizedCollection과 같은 상황이 있진 않을지 다시 한번 고려해보자

굳이 최상위가 아닌 의미를 분명히 구분 지어 놓은 하위 인터페이스에 만드는 게 더 나은 선택일 수도 있다

 

잡다한 개발 뉴스를 보다가 project loom 이란 걸 알게 됐고 얘네가 추구하는 게 뭔지 설명하는 글을 봤다

지금의 자바 멀티 스레드 프로그래밍은 RxJava, Reactor 등의 구현체를 활용해 멋들어지게 할 수 있지만

여전히 무겁고 굉장히 어려워 병아리들은 접근 금지 상태다

project loom에서는 가상 스레드를 이용해 가벼운 스레드를 만들어내고

블로킹 코드의 형태로 작성해도 논블로킹으로 돌아가도록 만들어준다, 세부 구현을 쟤네가 맡아서 처리해주기 때문이다

글 말미에 보면 완전히 대체하는 것은 아니라고 하기에 언제 나올지 모르는 project loom만 손가락 빨면서 기다릴 순 없다

요즘 보는 책들 여기저기에 다 동시성 얘기를 하니 언젠가는 자바 병렬 프로그래밍을 봐야겠는데 까마득하구나

 

Java의 동시성 개선을 위한 Project Loom은 reactive streams를 대체할 것인가?