변화로부터 코드를 보호하려면 추상화를 사용하라 #
" 함수와 클래스 등의 추상화로 실질적인 코드를 숨기면, 사용자가 세부 사항을 알지 못해도 괜찮다는 장점이 있습니다. 그리고 이후에 실질적인 코드를 원하는대로 수정할 수도 있습니다. “
” 추상화는 더 많은 자유를 주지만, 이를 정의하고, 사용하고, 이해하는 것이 조금 어려워질 수 있습니다. “
추상화 사례 1. 상수 #
리터럴은 아무것도 설명하지 않는다.
리터럴을 상수 프로퍼티로 변경하면 해당 값에 의미를 부여할 수 있다. 그래서 두 번 이상 사용되는 값은 상수 프로퍼티(변수)로 만드는 것이 좋다.
추상화 사례 2. 함수 #
Context.toast(),Context.snackbar()->Context.showMessage()로의 변경 예시
메시지의 출력 방법이 중요한 것이 아니고, 메시지를 출력하는 의도를 표현했다.
= 세부 사항은 숨기고 범용적인 이름을 사용했다.
의미 있는 이름은 굉장히 중요하다.
추상화 사례 3. 클래스 #
클래스가 함수보다 강력한 이유는 ‘상태’를 가질 수 있고, 많은 함수를 가질 수 있다는 점이다.
” 더 많은 자유를 얻으려면, 더 추상적이게 만들면 됩니다. (바로 인터페이스 뒤에 클래스를 숨기는 방법입니다. “
추상화 사례 4. 인터페이스 #
” 라이브러리를 만드는 사람은 내부 클래스의 가시성을 제한하고, 인터페이스를 통해 이를 노출하는 코드를 많이 사용합니다. 이렇게 하면 사용자가 내부 클래스를 직접 사용하지 못하므로, 라이브러리를 만드는 사람은 인터페이스만 유지한다면 별도의 걱정 없이 자신이 원하는 형태로 변경할 수 있습니다. “
인터페이스 뒤에 객체를 숨김으로써 실질적인 구현을 추상화하고, 사용자가 추상화된 것(인터페이스)에 의존하게 만들 수 있다.
= 결합성(coupling)을 줄일 수 있다.
추상화의 문제 #
추상화는 자유를 주지만, 코드를 이해하고 수정하기 어렵게 만든다.
즉, 추상화도 비용이 발생한다. 극단적으로 모든 것을 추상화해서는 안된다.
어느 정도 숨기면 개발이 쉬워지는 것도 맞지만 너무 많은 것을 숨기면 결과를 이해하기 힘들어진다.
추상화는 거의 무한하게 할 수 있지만, 어느 순간부터 득보다 실이 많아진다.
이를 풍자한 ‘FizzBuzz Enterprise Edition’ 이라는 프로젝트가 있다. 원래는 10줄도 필요하지 않은 코드가, 책 집필 시점 기준 61개의 클래스와 26개의 인터페이스로 작성됐다고 한다.
어떻게 균형을 맞춰야 할까? #
진리의 케바케인 것 같다.
팀의 크기, 팀의 경험, 프로젝트의 크기, 도메인 특징/지식 등에 따라 달라질 것이다.
- 많은 개발자가 참여하는 프로젝트는 이후 객체 생성, 사용 방법을 변경하기 어렵다. 따라서 되도록 추상화를 고려하는 것이 좋다.
- 테스트를 하거나, 다른 애플리케이션을 기반으로 새로운 애플리케이션을 만든다면 추상화를 사용하는 것이 좋다.
- 프로젝트가 작고 실험적이라면, 추상화를 하지 않아도 괜찮겠다. 문제가 발생하면 빠르게 수정하면 된다.
요약 #
- 추상화는 가독성↑ 코드 유지보수(변경)↑ 중복↓ 비용↑ 의 특징이 있다고 볼 수 있겠다.
- 추상화는 단순히 중복을 제거하기 위한 것이 아니다.
- 추상화는 코드를 변경할 때 도움이 된다.
- 추상화를 사용하는 것은 어렵지만, 이를 배우고 이해해야 한다.
- 장점과 단점을 비교하여 프로젝트 내에서 균형을 찾아야 한다.