📚책 정보
- 좋은 코드, 나쁜 코드 (2022)
- 톰 롱 (구글 소프트웨어 엔지니어) 지음
📝2장: 추상화 계층
1. null 값 및 의사코드 규약
2. 왜 추상화 계층을 만드는가?
3. 코드의 계층
4. 마이크로서비스는 어떤가?
📍클래스의 이상적인 크기
1. 줄 수
- 300줄 이내
2. 응집력(cohesion)
- 한 클래스의 모든 멤버들이 얼마나 잘 속해있는지
순차적 응집력
- A -> B 순서로 요소들이 필요할 때 (한 요소의 출력이 다른 요소의 입력에 필요)
- 예) 커피 원두를 갈고 -> 추출이 가능
기능적 응집력
- 한 가지 작업을 위해서 필요한 요소들 모두가 잘 모여 있는 것
- 예) 케이크 만들기 -> 반죽, 케이크 틀, 넓은 접시 등
3. 관심사의 분리(separation of concerns)
- 예를 들어, UI와 로직을 분리한다면, UI를 개선하기 위해 로직까지 변경할 필요가 없어진다
📍코드 계층화 4요소 관점에서 클래스 만들기
1. 가독성
- 단일 클래스에 담긴 개념이 많아지면 가독성이 나빠진다
2. 모듈화
- 클래스, 인터페이스 사용은 모듈화를 위한 좋은 방법
- 각 클래스가 잘 나뉘어 있고, 클래스들 간 상호작용이 몇 개의 퍼블릭 메서드로만 이루어지면 추후 코드 교체가 쉬워짐
3. 재사용성 및 일반화
- 여러 문제 해결을 위해 기존의 클래스를 재사용할 수 있다
4. 테스트 용이성
📍클래스 리팩토링 예시: TextSummarizer
리팩토링 전: 코드 계층화 4요소가 보장되지 않음
리팩토링 후: 코드 계층화 4요소가 개선됨
- 다른 문제를 해결할 때 ParagraphFinder 같은 클래스 재사용 가능
- 테스트 코드 작성이 쉬움
📍인터페이스
인터페이스를 통해 어떤 함수를 외부로 노출할지 결정할 수 있다
- 이 때, 인터페이스에 정의된 대로만 클래스를 구현한다
- 상위 계층은 하위 계층의 인터페이스에 의존할 뿐, 구체적인 클래스에 의존하지 않는다
- 이를 통해 계층 사이를 뚜렷이 구분하고 구현 세부 사항이 계층 사이에 유출되지 않도록 할 수 있다
하나의 추상화 계층에 대해 2가지 이상의 다른 방식으로 구현을 하거나,
향후 다르게 구현할 것으로 예상되는 경우, 인터페이스를 정의하는 것이 좋다
- 새로 구현할 때 인터페이스를 implements 하는 클래스를 만든다
- 기존 메서드를 오버라이드하여 클래스 안에 새 기능을 추가할 수 있다
📍TextSummarizer에 인터페이스 추가하기
앞선 예시의 TextSummarizer에 머신러닝으로 중요도를 평가하는 기능을 추가한다면..
- 인터페이스를 활용하여 기존의 단순히 단어를 평가하는 방법과 별개로 머신러닝을 활용하는 방법을 만들 수 있다
- 코드를 아예 교체하는 것이 아닌, 2가지 방법 중 하나로 코드를 구성하려고 하는 경우에 유리
주어진 추상화 계층에 대해 1가지 구현만 있고, 향후 다른 구현을 추가할 계획이 없더라도, 인터페이스를 통해 추상화 계층을 표현하는 것이 권고된다
- 인터페이스 뒤로 클래스를 숨겨, 사용자는 인터페이스에 정의된 메서드만 볼 수 있다
- 이 경우, 상위 계층은 인터페이스에 의존할 뿐, 구현 클래스에 직접 의존하지 않게 된다
📍인터페이스의 장단점
장점
1. 퍼블릭 API를 명확하게 보여준다
2. 테스트가 쉽다
3. 재사용성이 좋아진다
- 같은 클래스로 2가지 하위 문제를 해결할 수 있다
단점
1. 작업량 증가
2. 코드가 복잡해질 수 있음
- 로직의 이해를 위해 여러 파일을 봐야 함
클래스와 인터페이스를 너무 잘게 쪼개면 계층이 얇아질 수 있지만...
- 계층이 얇을 때 문제: 매우 적음
- 계층이 두꺼울 때 문제: 매우 큼
📍마이크로서비스 아키텍쳐(msa)
개별 문제에 대한 해결책이 독립적으로 실행되는 서비스로 배포됨
- 시스템이 여러 소규모 프로그램으로 분할되어 특정 작업만 전문적으로 수행
- 각 프로그램은 API를 통해 원격으로 호출되는 서비스로 배포됨
📍msa 예시: 이커머스의 재고 확인 서비스
재고 확인 마이크로서비스는 다음 상황에서 호출됨
- 제품이 새로 창고에 도착할 때
- 유저에게 재고를 보여주기 위해 프론트엔드에서 재고 확인
- 고객이 제품 구매할 때
상위 문제
- 고객의 범위 내에 있는 창고 결정
- 고객 주소 내의 창고의 재고를 찾기 위해 데이터베이스 쿼리
- 데이터베이스에서 반환되는 데이터 형식 해석
- 서비스 호출자에게 결과 반환
상위 문제 해결을 위한 하위 문제들
- 재고 항목의 개념: 실제로 무엇을 추적하는지?
- 보관 창고가 여러 곳일 때 처리하는 방법
- 실제 재고 데이터가 저장된 데이터베이스와 인터페이스
- 데이터베이스에 저장된 값의 해석
=> 여러 팀에서 재사용 가능