[🏝 이펙티브 코틀린] 4 추상화

🏐 item 26 함수 내부의 추상화 레벨을 통일하라

추상화 레벨 통일 원칙(Single Level Of Abstraction, SLA) 이란?

컴퓨터 과학이 높은 레벨과 낮은 레벨을 확실하게 구분하고 있는 것처럼, 함수도 높은 레벨과 낮은 레벨을 구분해서 사용해야한다는 원칙

 

높은 레벨의 모듈 - 비즈니스 로직

낮은 레벨의 모듈 - 입력과 출력을 나타내는 모듈(view, http 요청 처리 등)

 

계층이 잘 분리된 프로젝트 = 좋은 프로젝트

🏐 item 27 변화로부터 코드를 보호하려면 추상화를 사용하라

• 상수 추출
• 함수 (동작 래핑)
• 클래스 (함수 래핑)
• 인터페이스
• 특수한 객체 (보편적인 객체 래핑)

어떻게 균형을 맞출까?

추상화의 균형을 찾는 것은 거의 감각에 의존해야하는 예술에 가깝다. 그래도 사용할 수 있는 몇가지 규칙은 다음과 같다.

• 많은 개발자가 참여하는 프로젝트는 이후에 객체 생성과 사용방법을 변경하기 어려우므로 추상화 방법을 사용하는 게 좋다. 최대한 모듈과 부분(part)을 분리하자.
• 의존성 주입 프레임워크를 사용하면, 생성이 얼마나 복잡한지는 신경쓰지 않아도 된다. 클래스 등은 한 번만 정의하면 되기 때문이다.
• 테스트를 하거나 다른 애플리케이션을 기반으로 새로운 애플리케이션을 만든다면 추상화를 사용하는 게 좋다.
• 프로젝트가 작고 실험적이라면 추상화를 사용하지 않고 최대한 빨리 직접 변경하면 된다.

추상화를 사용할 때의 장점과 단점을 모두 이해하고, 프로젝트 내에서 그 균형을 찾아야한다. 추상화가 너무 많거나 너무 적은 상황 모두 좋은 상황이아니다.

🏐 item 28 API 안정성을 확인하라

API = Application Programming Interface

1. 안정적인 라이브러리로 업데이트하는 것을 두려워하지마라
2. 새로운 API 를 배워야한다.

모듈과 라이브러리를 만드는사람은 이들을 사용하는 사람들과 커뮤니케이션이 제일 중요하다.

또한 안정적인 API에 변경을 가할 때는 사용자가 적응할 시간을 충분히 줘야한다.

🏐 item 29 외부 API를 랩(wrap)해서 사용하라

불안정한 API를 과도하게 사용하는 것은 위험하다. 불안정한 외부 라이브러리를 사용할 경우 랩해서 사용해야한다.

🏐  item 30 요소의 가시성을 최소화하라

• 가시성 한정자 사용하기
  • 클래스 멤버
    • public
    • private
    • protected
    • internal
  • top level
    • public
    • private
    • internal

internal : 모듈이 다른 모듈에 의해서 사용될 가능성이 있을때, 공개하고 싶지 않은 요소를 숨긴다.

protected : 요소가 상속을 위해 설계되어 있을 때, 클래스와 서브클래스에서만 사용되게 만든다.

private : 동일한 파일 또는 클래스에서만 요소를 사용

 

아래 이유로 요소의 가시성은 최대한 제한적인 것이 좋다.

• 인터페이스가 작을수록 이를 공부하고 유지하는 것이 쉽다.
• 최대한 제한이 되어 있어야 변경하기 쉽다.
• 클래스의 상태를 나타내는 프로퍼티가 노출되어 있다면, 클래스가 자신의 상태를 책임질 수 없다.
• 가시성이 제한되면 API의 변경을 쉽게 추적할 수 있다.

🏐 item 31 문서로 규약을 정의하라

1. 이름
   1. 일반적인 개념과 관련된 매서드는 이름만으로 동작을 예측할 수 있다
2. 주석과 문서
   1. 함수 이름과 파라미터만으로 정확하게 표현되는 요소에는 따로 주석을 넣지 않는 것이 좋다.
   2. KDoc
   • 첫번째 줄 : 요약 설명
   • 두번째 줄 : 상세 설명
   • 그 뒤에 모든 줄 : @tag로 시작
     • @param <name> : 함수 파라미터 or 클래스, 프로퍼티, 함수 타입 파라미터
     • @return : 함수의 리턴 값
     • @constructor : 클래스의 기본 생성자
     • @receiver : 확장 함수의 리시버
     • @property <name> : 명확한 이름을 갖고 있는 클래스의 프로퍼티를 문서화
     • @throw <class>, @exception <class> : 메소드 내부에서 발생할 수 있는 예외
     • @sample <identifier> : 정규화된 형식 이름을 사용해서 함수의 사용 예시
     • @see <identifier> : 특정한 클래스 또는 메서드에 대한 링크 추가
     • @author : 요소의 작성자를 지정
     • @since : 요소에 대한 버전을 지정
     • @supress : 이를 지정하면 만들어진 문서에서 해당 요소가 제외
3. 타입
   1. 타입은 객체에 대한 많은 걸 알려준다. 어떤 함수의 선언에 있는 리턴 타입, 아규먼트 타입은 큰 의미가 있다. 자주 쓰이는 타입의 경우, 타입만 봐도 어떻게 쓰는지 알 수 있지만 일부 타입은 문서에 추가로 설명해야 할 의무가 있다

구현의 세부 사항은 항상 달라질 수 있지만 최대한 많이 보호하는 게 좋다. 일반적으로 캡슐화를 통해 보호한다.

캡슐화는 "허용하는 범위"를 지정하는 데 도움을 주는 도구다. 캡슐화가 많이 적용될수록 사용자가 구현에 신경을 많이 쓸 필요가 없어지므로 많은 자유를 갖게 된다.

특히 외부 API를 구현할 때는 규약을 잘 정의해야 한다.

🏐 item 32 추상화 규약을 지켜라