[Item15] 우아한 제약 걸기

객체지향의 핵심은 풀어 설명하면 한도 끝도 없지만 간단하게 보면 캡상추다로 요약된다

1. 캡슐화

2. 상속

3. 추상화

4. 다형성

 

이 중 캡슐화에 해당하는 내용이 Item15에 나오는데 외부에서의 접근 권한을 최소화하는 것이다

개인적으로는 컴포넌트의 손발 자르기라고 생각해 불호에 가깝지만 기술적으로 보면 맞는 말이기 때문에 따라야 한다

프로그램 유지보수의 난이도는 변경이 어디까지, 얼마나 전파되느냐에 따라 달라지기 때문이다

변경의 영향을 최소한으로 줄이기 위해 setter를 막아두고 특별한 이름의 메서드를 만들어 사용해야 한다

 

사실 setter를 열어두거나 필드를 public으로 열어두면 유연성이 향상된다

혼자 만드는 프로젝트라면야 세터를 열어두든 퍼블릭으로 다 열어두든 누가 뭐라하겠는가?

특히 내가 좋아하는 Entity-DTO 매핑 라이브러리 MapStruct를 사용할 때 그 진가가 발휘된다

JPA와 사용하면 setter만으로 값 변경이 가능하니 프로그램 작성이 쉬워진다

 

다만 개인 프로젝트가 아닌 회사나 오픈 소스 같은 대규모 프로젝트로 간다면 얘기가 달라진다

값이 너무나도 쉽게 바뀐다는 것이 장점에서 단점이 되버린다

컴포넌트의 손발을 자르지 않아서 어디로 가서 어떻게 변하는지 파악이 되지 않는다

유연성은 올바른 방식으로 접근할 때만 유용하다, 따라서 여럿이 참여하는 대규모 프로젝트라면

유연성에 제약을 걸어서라도 통일된 방식을 유도해야 하고 변경의 여파를 최대한으로 줄여야 한다

 

이펙티브 자바 전체에서 저자가 강조하는 것 중 특히 자주 나오는 것이 public API에 관해서다

외부에서의 접근을 열어둔 API는 하위호환성 때문에 사실 상 굳어지게 된다

더 좋은 코드가 생각나도 어지간해서는 바꿀 수 없다

제작자와 사용자의 계약이 체결 되어 버렸고 제작자 마음대로 계약을 되무를 수 없기 때문이다

이 개념이 구체화되어 계약에 의한 설계가 되었고 이 방식을 따르면 제작 과정에 더욱 주의를 기울일 수 있다

public API를 한번 바꾸게 되면 백엔드 코드 뿐만 아니라

프론트엔드 코드도 바뀌어야 할 수 있고, 사용자의 사용 방식 또한 달라져야 할 수 있다

 

기본적으로 private, package-private, protected 제한자를 이용해 꽁꽁 숨기자

필드는 private으로 만들어 접근을 막아두고 getter로만 접근해야 하며

변경의 이유가 없다면 불변으로 만들어야 한다, 변하지 않아야 믿고 쓸 수 있다

지금까지 배워온 내용을 바탕으로 내게 제일 어려운 부분은 사이드 이펙트와 동시성 문제다

수 많은 트래픽이 들어오는 상황에 하나의 객체를 여럿이 변경하고자 하는 문제를 어떻게 풀 수 있을까?

가장 쉬운 답으로는 변경하지 않으면 된다는 것이다

 

불변은 FP의 근간이고 말도 안 되는 처리량을 위한 필수조건이다

그렇다면 모든 객체를 불변으로 만들어버리고 외부의 접근을 다 막으면 기가 막힌 프로젝트가 탄생할 것인가?

맞긴 하다만 모든 객체를 불변으로 만들기란 쉽지 않다

따라서 무작정 다 숨기는게 해결책은 아니고 얼마나 우아하게 숨기느냐가 관건이다

일단 다 감추고 필요에 따라 서서히 제한을 풀어 나간다

그러다 public에 도착하면 다른 방법으로 풀 수는 없을지 고민할 타이밍이다

 

나는 어떤 상황에서도 기술보다 비지니스가 우선 되어야 한다고 생각한다

기술적으로 완벽한 라이브러리가 있어도 사용하지 않으면 무용지물이다

그렇다고 변화만 따라가고 코드 퀄리티를 땅에 처박아도 된다는 것은 아니다

개발 병아리가 할 말은 아니지만 빠르게 변하는 요구 사항에 대응하고 기술적으로도 완벽에 가깝게 노력하는 수 밖에?!