2. 추상화 계층

• 문제를 어떻게 해결하는가도 중요하지만 문제를 해결하는 코드를 어떻게 구성하는가도 중요
• 코드를 잘 구성한다는 것은 간결한 추상화 계층을 만드는 것으로 귀결될 때가 많다
• 서버에서 메시지를 보내는 코드
  • 연결, 보내기, 닫기
  • 그 하위 문제들을 인식할 필요 없음 → 추상화 계층
• 문제가 엄청나게 복잡할지라도 하위 문제들을 식별하고 올바른 추상화 계층을 만듦으로써 그 복잡한 문제를 쉽게 다룰 수 있다

 

추상화 계층 및 코드 품질의 핵심 요소

• 가독성
  • 한 번에 한두 개 정도의 계층과 몇 개의 개념만 다루면 됨
• 모듈화
  • 다른 계층이나 코드의 일부에 영향을 미치지 않고 계층 내에서만 구현을 변경하기가 매우 쉬워짐
• 재사용성 및 일반화성
• 테스트 용이성

 

API 및 구현 세부 사항

• 코드를 호출할 때 볼 수 있는 내용
  • 퍼블릭 클래스, 인터페이스 및 함수
  • 이름, 입력 매개변수 및 반환 유형이 표현하고자 하는 개념
  • 코드 호출 시 코드를 올바르게 사용하기 위해 알아야 하는 추가 정보 (예: 호출 순서)
• 코드를 호출할 때 볼 수 없는 내용
  • 구현 세부 사항
• 코드를 API 관점에서 생각하면 추상화 계층을 명확하게 만드는 데 도움이 됨

 

함수

• 각 함수에 포함된 코드가 하나의 잘 써진 짧은 문장처럼 읽히면 이상적

• sendOwnerALetter()
  • 소유자의 주소(차량이 폐기된 경우 폐차장 주소, 차량이 아직 판매되지 않은 경우 전시장 주소, 그렇지 않으면 차량의 마지막 구매자의 주소)를 찾아 편지 한 통을 보내라
  • 여러 가지 다른 개념을 한 번에 말하고 있기 때문에 좋은 문장이 아님
• ‘차량의 소유자의 주소를 찾아보고, 만약 발견되면, 그 주소로 편지를 보내라’
  • 차량 소유자의 주소를 찾는다
  • 주소를 찾은 경우 차량 소유자에게 편지를 보낸다
• getOwnersAddress()
  • 같은 클래스 내에서 재사용하거나 헬퍼 클래스로 옮기고 퍼블릭 메서드를 변경
• 코드의 가독성과 재사용성이 높아짐

 

클래스

• 줄 수
  • 300 줄 넘지 않아야 한다? → 경험적으로는 맞지만 실제로는 사용하기에 제한적
• 응집력
  • 순차적 응집력
    • 원두를 갈아내는 과정의 산출물은 커피를 추출하는 과정에 투입
    • 갈고 - 추출하는 것 사이에 서로 응집력이 있음
  • 기능적 응집력
    • 하나의 일을 성취
• 관심사의 분리

• 네 가지 핵심요소에 의해 판단
  • 가독성이 좋은가?
    • 여러 가지 다른 개념이 한 번에 구현
    • 코드 파악에 시간 오래 걸림
  • 모듈화되어 있는가?
    • 하위 문제를 해결하는 부분이 모듈화되어 있지 않음
  • 코드를 재사용하거나 일반화 할 수 있는가?
  • 코드를 제대로 테스트하기 쉬운가?

 

인터페이스

• 하나의 추상화 계층에 대해 두 가지 이상의 다른 방식으로 구현할 경우