우석

계층형 설계 2

패턴 2: 추상화 벽

추상화 벽은 세부 구현을 감춘 함수로 이루어진 계층을 뜻한다.
타 팀에서 제공하는 API를 생각해보면 이해가 쉽다. 이용부는 API Spec만 알 뿐 구체적인 구현은 모른다.
이런 구조에서는 아래와 같은 이점을 얻을 수 있다.
- 쉽게 구현부을 변경할 수 있다.
- 사용부에서 세부적인 것을 고려하지 않아도 되기 때문에 코드를 읽고, 쓰기 쉬워진다.
- 협업 시에 각 팀의 구체적인 작업에 대해서는 서로 알 필요가 사라진다.
- 세부적인 것을 고려하지 않을 수 있기 때문에 코드를 읽고 쓰는 작업 중에 현재 함수에서 풀고자 하는 문제에 더 집중할 수 있다.
각 계층에서 신경써야하는 것과 신경쓰지 않아도 되는 것을 구분하는 것이 추상화 벽의 핵심

작은 인터페이스는 기능이 추가될 때 어떤 계층에 부합하는지 고민하고, 각 계층에서 최소한의 기능만을 제공하여 크기를 최소한으로 조절하는 것을 지향하는 것이다.
계층에서 제공하는 기능이 많아질 경우 아래와 같은 문제가 발생할 수 있다.
- 각 계층에 기능이 많을수록 구현이 변경되었을 때 고쳐야 할 것이 많아진다.
- 기능이 많을 수록 상위 계층과 조율이 필요한 부분이 많이 발생한다.
- 또한 알아야 할 기능도 많아진다.
즉, 기능을 최소한으로 두고 새로운 기능이 필요할 경우 상위 계층에서 현재 제공되는 기능의 조합으로 만드는 것을 고려해보면 된다.
만약 현재 제공하는 기능을 조합하여 상위 계층에 만들 수 있는 기능이라면, 기능의 구체성을 고려할 때 상위 계층이 적합할 것이다.
또한 이 방향성이 직접 구현 패턴에도 더 부합한다.

계층형 설계를 설명하며 책에서는 함수 호출 그래프를 자주 제시한다.
호출 그래프를 보면 모든 함수를 계층에 기반하여 구조적으로 조망할 수 있다.
이때 계층에 따라 상/하위 함수들이 존재하게 된는데, 위치에 따라 유지보수성/테스트성/재사용성을 간단히 구별할 수 있다.
- 유지보수성: 상위 계층의 함수가 가장 고치기 쉽고 하위 계층은 그 반대이다.
- 테스트성: 하위 계층의 함수일수록 테스트의 가치가 높고 상위 계층은 그 반대이다. (다시 생각해보면 어떤 의도에서 한 말인지는 알지만 가치가 높고 낮다고 단정지을 수는 없을 것 같다.)
- 재사용성: 하위 계층의 함수일수록 재사용성이 높고 상위 계층은 그 반대이다.
여기서 유지보수성은 왜 외부에 노출되는 메서드가 상위 계층에 존재하는지를 이해할 수 있게 해준다. (변경 요구가 많을 것이기 때문이다.)

만혁

추상화 벽은 세부 구현을 감춘 함수로 이루어진 계층

추상화 벽에 있는 함수를 사용할 때는 구현을 전혀 몰라도 함수를 쓸 수 있다.

인터페이스를 최소화하면 하위 계층에 불필요한 기능이 쓸데없이 커지는 것을 막을 수 있다.

로그를 남기는 함수는 액션 이므로 잘 고려해봐야함! (액션은 전파 되기 때문)

앞 세 개의 패턴은 가장 이상적인 계층 구성을 만드는 방법에 대해 설명한다.

편리한 계층 패턴은 다른 패턴들과 다르게 조금 더 현실적이고 실용적인 측면을 다룬다.

작업할때 편리해야한다??? 뭔말인지;

-> 다시보니 개발하기 편하고 디버깅할때 편하다라는 이야기인듯