[Item05] 때려박는 코딩은 그만, 확장성을 고려하자

Item05는 자원을 때려 박지 말고 외부에서 주입받을 수 있도록 만들라는 것이 주요 내용이다

한 줄로 써놔서 간단해보이지만 객체지향의 핵심이라 할 수 있다

개인이 진행하는 토이 프로젝트가 아니라면 첫 출시와 비교해서 달라지지 않을 프로젝트는 없을 것이다

모두가 만족해할 기능은 없을 것이고 특정 기능에 다수가 만족하더라도 소수는 싫어할 수도 있다

마음 넓은 프로젝트는 구닥다리 IE의 낮은 버전까지도 지원해줘야 하고 그들만을 위한 기능도 추가해줘야 한다

 

계속해서 변화하고, 기존 코드에 추가되어야 할 코드가 잔뜩 있는데 기존 코드를 바꿀 수 없다면 어떻게 될까?

극단적인 예시지만 때려 박는 코드에선 현실이 된다 하위 호환성까지 알뜰살뜰 챙기는 자바에서 타격이 더욱 크다

공개 API는 쉽게 바꿀 수 없다 더 나은 코드가 무엇인지 알고 있는 상황에도 그렇다

그럼 이 같은 상황을 어떻게 피할 수 있을까? 답은 의존 객체 주입과 추상화다

 

스프링 관련 강의나 책에서 그렇게 울부짖는 두 녀석이다

객체지향 책들에서 자주 나오는 것 중 하나가 '책임을 분리하라'인데 생성도 곰곰이 생각해보면 다른 책임이다

인스턴스가 본질적으로 가져야 하는 책임은 사용될 책임이다, 어떻게 생성되는지는 몰라도 된다

그렇기 때문에 생성 책임을 외부로 넘겨 외부에서 알아서 생성하게 하고 인스턴스는 유용하게 쓰이면 그만이다

 

그렇다면 생성할 때 확장성 있는 방식은 어떻게 하면 얻을 수 있을까

필요한 인자를 가능한 한 최상위 타입으로 받으면 된다

Item을 상속하거나 구현한 Book이 있을 때 기묘한 요청에 의해 Movie로 바뀌어야 한다고 가정해보면

Book과 Movie는 Item의 하위 타입인 것만 공통적일 뿐, 둘은 비슷한 것이 없다

이럴 때 생성을 Book으로 해놨으면 공개 API의 경우, 하위 호환성을 개박살내고 Movie로 바꿀 것이다

지난 실수에서 배움을 얻는 이라면 Item으로 바꿀 것이다, 한발 더 나아가서 Item의 상위 타입으로 바꿀 수도 있다

 

공개 API가 아닌 회사 소유 프로젝트라면 큰 부작용 없이 바꿀 수는 있다

Book 인스턴스를 사용하는 모든 코드를 파악해서 새 코드로 갈아 끼우고

테스트도 추가 작성해주어야 하며  개발 / QA / 인수 테스트까지 수행해야 한다

또한 테스트를 수행하며 왜 그때 그 따위로 작성했을까 하며 자책할 일이 생긴다

 

그때는 맞았고 지금은 틀리다, 하며 넘어갈 수도 있는 일이지만 자신을 위해 조금 더 고민해보자

추후 확장성을 모두 고려할 수는 당연히 없고 개발 세계에 YAGNI라는 격언도 존재한다

단 YAGNI의 설명을 보면 아래와 같은데 바꿔 말하면 필요하다고 간주되는 순간 바로 추가할 수 있어야 한다

그러려면 확장성 있는 코드로 작성이 되어있어야 하겠다

프로그래머가 필요하다고 간주할 때까지 기능을 추가하지 않는 것이 좋다는 익스트림 프로그래밍(XP)의 원칙이다

https://ko.wikipedia.org/wiki/YAGNI

 

미래에 괴로운 일을 조금이라도 줄이려면 연관성 있는 각 객체들의 공통적인 부분을 뽑아내 최상위 타입으로 만들고

메서드 매개변수를 그 타입으로 받는 습관을 들여보자