[인프콘 2023] 점진적 추상화

점진적 추상화

추상화 방향

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

추상화 범위

• 추상화 방향 예측은 매우 어렵다.
• 추상화의 범위를 좁혔다면 어땠을까?
• 코어 로직만 추상화
• 너무 넓은 범위를 추상화 할 경우, 인터페이스 변경 위험에 더 많이 노출됨
• 인터페이스 추상화는 필요한 만큼만 하자.
  • 범위를 얼마나 가져가냐에 따라 이름과 메서드가 바뀐다.
• 추상화를 고민할 때는…
  • 추상화 범위가 필요한 부분에서만 이뤄지고 있는지를 점검하자

추상화 시기

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

변화무쌍한 요구사항을 유연하게

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

요약

• 추상화는 비용이 있고, 잘못된 추상화는 혜택없이 비용만 감당해야 되기도 한다
• 추상화는 적절한 방향, 범위, 시기를 고민해야
• 함수를 추출하는 것부터 점진적으로 시작하자