[이펙티드 코틀린] 4장 🖼️ 추상화 설계 Abstraction Design (item 26..32)

by Scott Carroll

item26 : 함수 내부의 추상화 레벨을 통일하라

추상화 계층화

• 어떤 계층에서 작업할 때 그 아래 수준의 층은 깊게 생각하지 않아도 된다
• 높은 레벨일수록 단순함을 얻고, 제어력을 잃는다.

추상화 레벨 통일

• CS 와 같이 코드또한 계층화가 가능한데, 이를 위한 기본적인 도구가 함수이다.
• 함수에서 SLA 추상화 레벨 통일 원칙을 통해 추상화가 가능하다.

아키텍처 추상화

• 아키텍처 수준에서 추상화하여 서브시스템의 세부 사항을 숨겨 상호 운영성과 플랫폼 독립성을 얻을 수 있다.
• 이는 문제 중심으로 프로그래밍 할 수 있음
• 모듈을 분리하여 계유의 요소를 숨길 수 있다.

item27 : 변화로 부터 코드를 보호하려면 추상화를 사용하라

상수 추상화

val MAX_THREADS = 10

• 상수를 추출하여 이름을 붙여 관리
• 가독성을 주고 쉽게 변경할 수 있다.

함수 추상화

• 일반적인 알고리즘을 추출하여 추상화

  fun Context.toast(  
    message: String,  
    duration: Int = Toast.LENGTH_LONG
  ) {
    Toast.makeText(this, message, duration).show()
  }

클래스 추상화

• 함수에 비해 상태를 가지고 많은 함수를 가질 수 있다.
• open 클래스를 활용하면 더 추상화 가능

인터페이스 추상화

• 인터페이스 뒤에 클래스를 숨겨 완전히 추상화 가능
• 추상화 된 것에만 의존하여 coupling을 줄일 수 있음 (DIP)
• 코틀린은 멀티플랫폼 언어라서 인터페이스를 리턴하기 좋아함
• 테스트에서 구현된 클래스 mocking보다 인터페이스 faking이 쉬움

추상화가 만능은 아니야

• 자유를 주지만, 코드를 이해하고 수정하기 어렵게 한다.
• 추상화도 비용이므로 극단적으로 추상화하지 말어
  • 팀 상황에 적절히 맞춰서
• 추상화를 이해하고 싶다면 예제를 살펴보자

item28 : API 안정성을 확인하라

• @Experimental
• @Deprecated
• ReplaceWith

item30 : 요소의 가시성을 최소화하라

왜요?

• 접근자의 가시성을 제한해서 모든 프로퍼티를 캡슐화하면 좋다
• 가시성이 제한되면 클래스의 변경을 쉽게 추적할 수 있다.
• 동시성을 처리할때 상태 변경은 병렬 프로그래밍에 위험하다.

그거 어떻게함

• public
• private
• protected
• internal

근데 DTO같은 데이터 클래스에는 쓰지말자

item31 : 문서로 규약을 정의하라

• 예상되는 행위를 문서로 설명하여 해결
• 서로가 규약을 존중하면 독립적으로 작업해도 모든 것이 정상적으로 기능할 것.
• 코틀린은 kDoc

item32 : 추상화 규약을 지켜라

• 리플렉샨 같은걸로 마법부리면 보증 안해줍니다