[8주차] 07. 캡슐화 (7.4~끝)

[DaehunGwak]

진도

7. 캡슐화 (7.4~끝)

방식

• 코멘트로 자유롭게 느낀점 (좋았단 점) 을 적어주시면 됩니다.
• 질문, 다른 좋은 참고자료, 실무 적용 사례 등을 공유해주셔도 좋습니다.

[donghoon-song]

7.1 레코드 캡슐화하기

7.2 컬렉션 캡슐화하기

가변 데이터를 모두 캡슐화 → 데이터 구조가 언제 어떻게 수정되는지 파악하기 쉬움, 필요한 시점에 데이터 구조를 변경하기도 쉬워짐

컬렉션에 대해서는 어느 정도 강박증을 갖고 불필요한 복제본을 만드는 편이, 예상치 못한 수정이 촉발한 오류를 디버깅하는 것보다 낫다.

7.3 기본형을 객체로 바꾸기

단순한 출력 이상의 기능이 필요해지는 순간 그 데이터를 표현하는 전용 클래스를 정의한다.

처음에는 그리 대단해 보이지 않을 수 있지만 코드베이스에 끼치는 영향은 엄청나다.

7.4 임시 변수를 질의 함수로 바꾸기

임시 변수를 사용하면 값을 계산하는 코드가 반복되는 걸 줄이고, 변수 이름을 통해 값의 의미를 설명할 수도 있어서 유용하다. 하지만 아예 함수로 만들어 사용하는 편이 나을때가 많다.

함수로 만들어두면 재사용성이 좋다.

자고로 변수는 값을 한 번만 계산하고 그 뒤로는 읽기만 해야 한다.

7.5 클래스 추출하기

7.6 클래스 인라인하기

더 이상 제 역할을 못 해서 그대로 두면 안 되는 클래스는 인라인한다.

특정 클래스에 남은 역할이 거의 없을 때

7.7 위임 숨기기

캡슐화는 모듈들이 시스템의 다른 부분에 대해 알아야 할 내용을 줄여준다.

7.8 중개자 제거하기

1. 위임 객체를 얻는 게터를 만든다.
2. 위임 메서드를 호출하는 클라이언트가 모두 이 게터를 거치도록 수정. 하나씩 바꿀 때마다 테스트
3. 모두 수정했다면 위임 메서드 삭제

7.9 알고리즘 교체하기

[minkukjo]

느낀 점

7.5~ 7.8까지는 큰 내용은 없었던 것 같다.
다만 7.7의 위임 숨기기를 하면서 든 생각이 있는데, 저자가 Client와 서버를 예시로 들길래 얘기해보면 좋을만한 내용이 생각이 났다.
서버와 클라이언트는 서로 데이터를 주고 받기 위해 모델을 사용하는데 개발하다보면 ( Request, Response )이 모델이 바뀌는 경우가 꽤나 빈번하다.
그럼 이 리퀘스트를 바꾸기 위해 저자는 위임 숨기기를 사용해 캡슐화를 하여 이러한 변화를 최소화한다고 하는데, 다들 실무에선 어떻게 이러한 문제를 고민하고 있는지 궁금하다.
그리고 마지막의 알고리즘 교체하기는 사실상 복잡한 for문을 람다 메소드로 바꾸면서 간결하게 바꾸는데 원본 코드가 너무 말도 안되서... 당연한거 아닌가? 라는 생각이 들었다.
그냥 장황한 알고리즘이 보이면 간결하게 줄여야한다 정도로 이해했는데 님들의 생각은 어떠한지 궁금함.