[ITEM 17] 변경 가능성을 최소화 하라

이번 이팩티브 자바에서 소개하는 챕처는 꽤나 긴편이다

중복된 이야기가 자주 나오지만 그 이유는 중요하기 때문에 반복하고 강조하는것이다

 

해당 챕터를 읽고 내가 생각하는 조슈아 블로크가 독자들에게 전달하고 싶은 키워드는 바로 캡슐화이다.

캡슐화는 모든 소프트웨어의 기본 근간이 되는 아주 중요한 개념이다 

캡슐화를 통해 많은 장점을 가질 수 있다. 

 

객체의 변경 가능성을 최소화 하면 코드의 변경이 유연하고 쉬워진다

이렇게 들으면 뭔가 논리적으로 안맞는것 같지만 사실이다

캡슐화를 통해 얻을 수 있는 가장 큰 장점 중 하나는 객체들간의 결합도를 낮출 수 있다. 

 

책 OBJECT의 저자 조영호는 기능을 수정하는데 클래스 하나 이상 수정을 해야한다면 그건 결합도가 높다고 말하기도 했다. 

결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수 있다. 

다시 말해 하나의 모듈을 수정하기 위해 얼마나 많은 모듈을 함께 수정해야 하는지를 나타낸다. 따라서 결합도가 높으면 높을수록 함께 변경해야하는 모듈의 수가 늘어나기 때문에 변경하기가 어려워진다. 

 

결합도를 낮춘다는 것은 또한 각 객체들의 자율성을 올려준다는 의미이기도 하다 

해당 클래스의 수정이 일어나도 사이드 이팩트 (side effect) 영향이 낮기 때문에 수정이 용이해지고 안전하다

 

여기서 끝이 아니다 

캡슐화는 자신의 상태를 꽁꽁 숨기기 때문에 불변 객체이기도 하다

불변 객체로 얻을 수 있는 이점은 지난번에도 설명을 했지만

스레드 안정성을 얻을 수 있다는 점이다

 

가변 상태를 가진 인스턴스는 스레드가 상태에 접근할 때 동기화에 심혈을 기울여야 한다 

하지만 불변은 간단하다 애초에 스레드 안전하기 때문에 마음 놓고 사용할 수 있고 

좀더 비즈니스 로직에 집중할 수 있다. 

 

이제 캡슐화의 칭찬은 여기까지 하고 실질적으로 어떻게 변경 가능성 있는 코드를 작서할지 알아보고 마무리 하겠다. 

1. 객체의 상태를 변경하는 메서드(변경자를) 제공하지 않는다 즉 setter 함수 제공 하지 않는다
2. 클래스를 확장하지 않는다 (해당 내용은 다음 챕터에서 이야기 하겠지만) 즉 상속을 말한다 
   확장대신 컴포지션을 사용하는데 다음 챕터에 컴포지션에 대해 설명하겠다.
3. 모든 필드를 private으로 선언한다
4. 자신 외에는 내부의 가변 컴포넌트에 접근할 수 없도록 한다
   클래스내에 참조하는 객체가 있다면 클라이언트에 그 객체의 참조를 얻을 수 없게 해야한다
   가령 List의 경우 Collections.unmodifiableList() 불변 리스트로 반환하여 외부에서 변경하지 못하도록 막아야한다. 

이처럼 캡슐화는 매우 중요하며 

기본적으로 설계를 시작할 땐 무조건 불변으로 시작할 것을 권장한다.