여러 구체적인 것에서 중요한 것만 남기고 나머지를 덜어내는 것. 객체 사이의 관계에서 위에 있는 것은 언제나 아래보다 추상적이어야 한다.
도메인이 정하는 기준
무엇이 중요한지는 누가 보느냐에 따라 달라진다. 책상은 그것을 만드는 사람과 앉아 쓰는 학생과 옮기는 이삿짐센터 직원에게 각각 다른 물건이다. 자동차도 타는 사람과 만드는 제작자와 정비공이 각각 다른 곳을 본다.
그래서 추상화의 기준은 비즈니스 영역, 곧 도메인이 정한다. 고객에게서 받아야 할 정보가 이름과 성별과 나이뿐이라면 필드도 그것뿐이면 된다. 먼 미래까지 대비해 쓰지도 않을 필드와 메서드를 미리 얹어두는 것은 추상화가 아니다.
추상체를 두는 이유
추상체를 따로 두는 이유는 다형성에 있다. 추상체로 선언해두면 그 자리에 어떤 구상체가 들어와도 쓰는 코드가 그대로다. 카카오 로그인이든 네이버 로그인이든 Login 타입으로 받으면 호출하는 쪽은 바뀌지 않는다.
추상체가 없으면 다형성이 성립하지 않는다. 다형성이 없으면 의존성 주입도 DIP도 의미를 잃는다. 밖에서 주입을 받아봐야 받는 타입이 구체 클래스로 고정되어 있으면 갈아 끼울 것이 없기 때문이다. 추상화를 나머지 설계 원칙의 전제라고 부르는 것은 그래서다.
추상체와 구상체를 가르는 수준
얼마나 추상화할지는 정도의 문제이고, 추상체와 구상체를 가르는 수준은 대략 세 단계로 본다.
가장 느슨한 것은 양쪽 다 구체적인 기능을 갖고 있고 의미로만 묶어둔 상태다. 다음이 추상 클래스로, 일부는 구현해두고 나머지는 자식에게 맡긴다. 가장 추상적인 것이 인터페이스다. 아무것도 구현하지 않고 명세만 준다. 아래로 갈수록 갈아 끼울 수 있는 범위가 넓어진다.
공통 코드를 빼려는 상속
상속 관계는 위로 갈수록 추상화되고 아래로 갈수록 구체화된 모습이어야 한다. 공통 코드를 빼려고 상속하면 이 구도가 깨진다. 위에 있는 것이 아래보다 추상적이지 않게 되고, 부모 자리에 자식을 넣어도 문제가 없어야 한다는 LSP도 함께 무너진다.