[Item16] 잘 숨겨야 발전한다

객체지향의 달인이 되려면 뭐든 간에 잘 숨겨야 한다, 객체지향을 처음 배울 땐 이 개념에 의문이 들었다

어차피 외부에서 쓰려고 만드는 건데 왜 숨겨야 하는가?

결합도를 낮추고 응집도를 높이기 위해서라는 말로는 이해하기 부족했다

불변 객체가 아니라면 인스턴스 변수들은 final이 아닐 것이고 변경 가능하다

접근 제한자까지 public이라면 어디서든 값을 변경할 수 있다

이는 엄청난 자율성을 주지만 시간이 지나면 참혹한 대가가 따른다

 

H/W, S/W 성능 향상으로 인해 변하지 않을 코드는 없다

이 정도면 기가 막히구만 하고 짰더라도 다음 버전에서 그 성능을 한참 앞지르는 알고리즘이 나올 수도 있고

절차 지향에서 객체지향으로, 객체지향에서 리액티브로 패러다임이 바뀌어버릴 수도 있다

가장 흔한건 역시 클라이언트의 요구사항 변경일 것이다

이런 상황에 어떻게 해야 쉽고 빠르게 대응할 수 있을까?

 

그 답이 모든 걸 숨겨버리는 것이다

클라이언트에게는 허용된 API만 제공하여 프로그램이 작성자의 의도를 따라 흐르게 만들어야 한다

이용하는 라이브러리의 성능이 아쉽다고 하여 정도의 길을 벗어나 사파적인 코드를 만들게 되면

라이브러리가 버전 업하며, 앞으로 계속될 성능 향상의 이점을 제 때 누릴 수 없을 것이다

물론 라이브러리가 너무 형편 없을 수도 있지만 그럼 애초에 쓰지 않았을 것이다

그럴 땐 어쩔 수 없이 직접 만들거나 라이브러리의 깃허브로 찾아가 당장에 이슈 제기하자

 

접근 제한자에 대해서 배울 땐 private, default, protected, public 아 요런 게 있구나 하고 넘어갔는데

깊게 들어가보면 하나하나가 다 트레이드오프를 어디까지 할 것인가에 대한 고민이 담겨있다

걸작들처럼 심혈을 기울여 작성할 수 있는 게 아니라면 기본은 모든 걸 private으로 가져가고

감춰뒀더라도 값을 알 방법은 필요하니 접근자나 계산 결과를 반환해주는 메서드를 열어두자

생각이 바뀌어도 private을 열기는 쉬우나 public을 닫기는 어렵다

이미 흩뿌려진 코드들이 많기 때문이다, 잘 숨겨놔야 언제라도 바꾸기가 쉽다

 

닫았을 때의 장점은 내부 구현을 천지개벽할 수준으로 바꿔도 클래스 밖에선 고요하다는 점이다

가끔 흐름을 따라 내부 구현으로 깊이 따라가보면 코딩 테스트가 생각날 정도의 난해한 코드들도 있다

private으로 막아뒀기에 작성할 수 있는 코드고, 성능을 극한으로 끌어올린 최적화의 결과물일 것이다

그 난해한 코드를 이해하지 않더라도 API 문서를 보면 얼마든지 활용할 수 있다

초보때는 개념을 우선 받아들였기에 이게 왜 이렇게 돼? 싶은 게 많았는데

깊이 알수록 이렇게 될 수 밖에 없겠구나 하는 생각이 든다

잘 작성된 라이브러리를 따라 약간의 제약을 걸되 올바른 방식으로 사용할 수 있도록 유도해야겠다

 

요즘 개인 프로젝트를 진행하면서 사용하는 라이브러리 중 log4j2-slack-appender나 p6spy 같은

작은 규모의 프로젝트는 흐름이 어떻게 되어있는지 자세히 살펴보고 있다

직접 고치진 못해도 이 부분은 조금 아쉬운데? 싶은 게 몇개 있다

내공이 좀 더 쌓이면 오픈소스에도 기여해보고 싶다, 언젠가는 할 수 있지 않을까?!