[리팩토링 2판] 7장 캡슐화

우선 컬렉션과 레코드의 개념부터 되게 모호해서 이해하기 힘들었다. 그래도 지피티랑 같이 공부하면서 어떻게든 이해하려고 노력했다.

 

레코드 캡슐화, 컬렉션 캡슐화를 읽고 드는 생각

• 생각보다 유용한 것 같다.
• 레코드와 컬렉션은 단순히 클래스화하는게 아니라, 추상화된 "데이터를 표현하는 방식"이다.
• 내가 평소에 리액트 상에서도 유저 정보를 상태로 관리하거나 비즈니스 로직을 상태로 관리하는 것 또한, 레코드와 컬렉션이라고 볼 수 있는 것이다.
• 대신 데이터를 객체가 아니라 클래스로 감싸면, 원본 데이터를 변경하는 부분이나 데이터를 가져오는 부분을 검증하거나 예외처리를 하도록 제어하기가 쉬워진다.
• 모든 레코드를 클래스화하는 것은 바람직하지 않겠지만, 정말 중요한 비즈니스 로직의 데이터의 경우에는 일괄적으로 캡슐화해서 관리해보는 것도 좋을 것 같다.
• 다만 확실한건 캡슐화를 도입하면 성능이 나빠질 수도 있다는 것이다.

 

 

기본형을 객체로 바꾸기

굳이 기본형을 객체로 바꿔야 싶었는데, 생각보다 유용한 것 같다. 특히 전화번호 문자열. 전화번호 문자열의 경우, "-"를 붙여야하는 경우도 있고, 떼야하는 경우도 있고 시작 번호를 통일해야하는 경우도 있고, 의외로 코드가 난잡해지기 쉽다. 이런 전화번호 문자열을 캡슐화해서 하나의 타입, 일관된 메서드로 관리하면 편하지 않을까싶다.

 

 

레코드와 값 객체의 차이점

레코드드는 단순히 데이터를 표현하는 방식으로 불변성이나 데이터 간 비교에 대한 로직이 없다. 그래서 typescript에서는 interface로 레코드를 선언할 수 있다. 그에 반해, 값 객체(Value Obejct)는 불변성을 갖추고, 동등성 비교 로직을 캡슐화한다. 값 객체는 단순히 데이터의 묶음일 뿐만 아니라 데이터의 동일성을 판단할 수 있는 기능을 포함하고, 값의 변경을 방지한다고 한다.

 

전화번호, 사업자등록번호, 이메일 등의 기본형 데이터이지만 검증 로직이 필요하거나 불변성을 지켜야하는 비즈니스 로직 상의 중요한 데이터의 경우, 값 객체를 도입하는 것도 좋을 것 같다.

 

 

## 그외

 

그 외에 클래스 인라인하기, 중개자 숨기기 등은 당장은 어떻게 활용할지는 잘 모르겠어서 굳이 적지는 않았다. 추후에 클래스를 깊게 쓰게된다면 필요하지않을까?