한참 SOLID 원칙을 따르며 GOF의 디자인패턴이 유행하고, MVP 설계방식이 아키텍처 시장을 점령했을 때

아직 비동기 콜백과 이벤트 콜백으로 코드가 범벅되기 전

대부분의 기능은 모두 Impl 같은 접두사를 붙여 위임하여 사용했습니다.

Spring이 그랬고, 모듈화가 최대 관심사였을 때 우리 정부는 전자정부 프레임워크를 만들었습니다.

지금의 프로그래머들은 진입장벽만 높다고 하겠지만, 대통령이 직접 프로그래밍의 가능성에 관심을 가졌던 시기였습니다.

그런 시대를, 저는 나름 좋아했습니다.

물론 느려터진 이클립스와 못생긴 JAVA6, 그리고 끊임없는 프로젝트 빌드 오류를 버텨내야 했지만 말이죠.

이때는 기능 하나하나를 모두 위임해서 작업했습니다.

이러한 위임은 장단점이 많았는데, 적어도 남의 코드 때문에 내 코드가 망가지는 일은 막을 수 있었습니다. 공장 같이 돌아간다고 할 수 있겠네요.

어찌 되었든 공통된 코드를 가진 비슷한 기능을 상속하지 않고 위임해서 쓴다는 것은 귀찮습니다. 또, 공통된 코드를 사용하기 위해 상속해서는 안 됩니다.

이는 SOLID 원칙에 어긋납니다.

만약 클래스만으로 이를 구현해야 한다면 Builder 패턴이나 특정 기능을 Actor가 소유하고 있어야 합니다.

공통된 코드를 복사 붙여넣기하면서 몇십 번…

추상메소드를 보조하는 메소드가 있었으면 하고 생각했습니다.

그렇게 시간이 흘러, 자바는 default 메소드를 공개했습니다.

default 메소드의 핵심은 추상메소드의 작동을 보조하는 것입니다.

제너릭스의 타입 추론이 향상되면서 더는 변수를 캐스팅해야 하는 메소드가 필요 없어졌습니다.

이제 1기능 = 1인터페이스가 아니라

프로그램의 흐름 속 어떤 시점에서 작동되어야 하는 동작을 사용자가 즉석 만들어 조합합니다.

예로 Calculable과 Calculator, CalculListener 세 가지 인터페이스의 사용을 보죠.

위의 코드는 어떠한 객체 두 개를 연산해야 할 경우를 다루고 있습니다.

public static <T,R> void calcul 메소드가 불편해 보이지만, 한번 선언하고 나면

어떠한 객체가 들어와도 대응할 수 있습니다.

우리는 일전에도 이런 코드를 짜고 싶었지만

멍청한 제너릭스와 거추장스러운 익명클래스로 인해

강제 캐스팅과 instanceof를 사용하면 안 된다는 관념 때문에 짜지 못하고 있었습니다.

그동안 코드는 엄격해졌고 서로를 인정하지 않은 채 붙이기만 하면 삐거덕거렸죠.

분명 모듈/라이브러리 형태로 구성하였지만, 내 사양에서만 동작하고 사용자의 사양에서는 동작하지 않는 경우가 허다했습니다.

이러한 문제점을 없애기 위한 것이 서술적으로 프로그래밍하는 것입니다.

구성하다 보면 기능 하나에 여러 Listener가 붙을 수 있습니다.

하지만 메소드가 완성된 상태에서 Listener 객체를 리스트로 넘기는 것은 좋지 않습니다.

그래서 우리는 andThen이라는 default 메소드를 추가로 구현할 겁니다.

저는 이번 java8 업데이트 중 andThen이라는 메소드가 가장 마음에 듭니다.

이 코드에서 주목해야 할 점은 default 메소드는 오로지 추상메소드를 보조하는 역할로 구성되어야 한다는 것입니다.

default 예제 대다수는 사용법만 알려주다 보니 인터페이스를 명사 형태로 사용하거나 개념적인 의미로 표현하는 경우가 있습니다.

예를 들어 interface car{...} 같은.

단순히 default 메소드를 사용할 수 있다고 클래스처럼 인터페이스를 사용해서는 안 됩니다.

인터페이스의 핵심은 기능을 추상화하는 것입니다.