점진적 추상화

if문 구현
- 타입이 늘어날수록 if문을 계속 추가해야 할텐데…
- 확장에 닫혀있는 코드가 되어버린다. (OCP 위반)
타입을 축으로 추상화를 할 수 있다.
- interface ← class
- 인터페이스 자체를 변경하는 것은 쉽지가 않다.
  - 하위 구현체들이 모두 영향을 받음
- 타입을 축으로 vs 행위를 축으로
  - 타입을 축으로 → 타입 확장에 유리
  - 행위를 축으로 → 행위 확장에 유리
어느 방향으로 발전할지 알기는 쉽지 않다.
- 소프트웨어 발전 방향과 일치하지 않는 추상화는 오히려 더 유지보수하기 힘든 코드가 발생된다.
현실은 더 많은 축이 존재…
- 다른 방향으로 확장할 가능성이 큼
- 초기 추상화의 모습과 현실이 전혀 다른 방향으로… → 괴리 발생
- 요구사항에 비해 훨씬 복잡해짐
- 추상화를 했음에도 불구하고 유지보수가 어려워짐

요구사항은 끊임없이 변경된다.
if문으로 쭉 늘어놓다 보면, 어떤걸 기준으로 추상화를 할 수 있을지를 느낄 수 있다.
- Adapter..?!
과거의 코드는 그 위치에 있다는 사실만으로도 상당한 영향력을 가진다
- 과거의 코드를 변경하는 것…
- 이것을 뒤엎고 추상화를 완전히 뒤집는 것은…
- 실무에서는 개발 초기단계에서 수행한 추상화는 더이상 동작하지 않을 수도…
- 때로는 날 것의 코드가 좋은 인사이트를 주기도 한다.
  - 함수 단위로 잘 쪼개져 있어야 한다. → SRP !!! 중요
인터페이스 추출 시, 구현체들은 보이지 않는 의존성을 가진다.
- 구현체들끼리는 보이지 않는 의존성이 있다.
- 클래스 추출에서 멈추는것도 하나의 방법이다.
처음부터 인터페이스 정의보다는 함수 분리부터 시작하고, 클래스 분리로 응집도 확보 → 적절한 추상화 시기를 탐색
개발 기능을 구현하는 초기 단계에서 좋은 추상화를 만들어내기는 쉽지 않다.

인터페이스 변경은 전체 구현에 영향
파라미터도 추상화를 할 것인가?
- 어떤 클래스에는 필요가 없는 파라미터일 수도 있는데… (nullable..?)
- 함수가 일급 객체인 언어에서는 콜백 메서드로 회피 가능하다.
  - 함수를 파라미터로 받으면 된다.
  - 하위 구현체들이 인터페이스로 강하게 묶이지 않게 된다.