[Item17] 가변으로 할까, 불변으로 할까

가변과 불변에 대한 좋은 글이 있다, 읽고 시작하자

Just Enough FP: Immutability

 

객체를 가변과 불변으로 만드는 절대적 기준은 딱히 없고 어떤 부분에 중점을 둘 것인지에 따라 달렸다

즉 애플리케이션을 만들 때 모든 객체를 가변으로 만들어도 되고 불변으로 만들어도 된다

다만 그 대가로 극심한 난이도의 유지보수성이나 지하로 곤두박질 친 성능이 따라올 수 있다

 

가변 객체는 귀요미 프로젝트일 땐 상관 없지만 며칠에 걸쳐 소스를 봐도 구조를 파악할 수 없을 때 문제된다

프로그램 작성자 중 하나라면 흐름을 모두 꿰뚫고 있지만

다른 이가 볼 때 객체가 어디서, 언제 변경되는지 어떻게 다 알 수 있을까?

또한 우리의 코드가 낡아갈 때 문제는 심화된다

자신이 작성한 코드 중 1년 전, 심하면 한달 전 코드도 이해하기 어려울 때가 있다

따라서 레거시는 피할 수 없으니 통용되는 관례를 따라 작성하는 것이 중요하다

 

언제 보더라도 이해할 수 있도록 클라스 있는 코드를 작성해야 한다

그렇기에 변수나 메서드의 네이밍이 중요한 것이다

객체가 수행하는 행동에 대한 사전 정보가 없더라도 변수명, 메서드명을 읽는 것만으로도

무슨 일을 하는 메서드인지 파악할 수 있어야 하겠다

나도 코드 작성 시에는 나름 신경 쓰며 작성한 메서드도 코드 리뷰를 받을 땐 털리기 일쑤다

고민이 부족했던 결과인 것 같다

 

그런데 이보다 더 쉽게 애플리케이션을 만드는 방법이 있다

바로 객체를 불변으로 만들어 변경 자체가 일어나지 못 하게 만드는 것이다

엔티티 설계는 정말 치밀하게 하면서 DTO는 조금 느슨하게 두는 이유이기도 하다

엔티티는 변경이 일어나면 DB에도 반영되고 

 

메서드 또는 함수에는 값을 넣어 연산의 결과 값을 받을 뿐이다

객체의 상태를 변경시키지 않으며 객체가 가진 값만을 이용하기 때문에 부작용이 없다

이는 동시성 문제에서 완전 해방될 수 있게 만들어준다

 

대신 상태 변경이 필요할 땐 값을 다르게 만든 새로운 객체가 필요하다는 것이 문제다

필요에 의해서 수 많은 인스턴스 필드를 가진 객체가 있을 때도 불변 객체라면 새로 만들어야 한다

이 점 때문에 가변과 불변 사이에서 줄타기를 해야한다

가변으로 만들면 변경이 쉬운 대신 시스템의 복잡성이 오르고 불변으로 만들면 복잡성은 낮아지는 대신 성능이 떨어질 수 있다

 

이런 어려운 상황에서도 프로그래머는 답을 찾아왔다

성능 향상을 위해 가변으로 두었을 때

1. 쉽게 변경되지 않도록 Setter 대신 의미 있는 이름을 가진 변경 메서드를 사용하거나

2. 계층을 명확히 분리해 핵심 로직 안에서만 변경을 수행하거나

3. 객체는 변하더라도 DB에는 반영되지 않도록 트랜잭션으로 제어하거나

 

복잡성을 낮추기 위해 불변으로 두었을 때

1. 내부에 private 가변 필드를 두고 값을 캐싱해두거나

2. 필드만으로는 부족한 경우, 가변 도우미 클래스를 이용하는 등의 묘수가 있다

 

가변과 불변에 대한 통찰이 부족해 여기까지만 써야겠다

새로 깨달음을 얻으면 업데이트 해야지