공개 함수가 다른 공개 함수를 호출하지 않도록 하자

공개 함수끼리 구현을 재사용해야 한다면, 서로 호출하기보다 비공개 공통 헬퍼를 추출해 두 함수가 호출하도록 하는 경험칙을 권함 공개 API는 외부 호출자가 쓰기 편해야 하지만, 내부 구현에도 재사용하면 외부 사용자와 내부 구현의 요구가 충돌할 수 있음 이 충돌은 사용자가 설정하면 안 되는 선택적 매개변수가 늘어나는 형태로 나타날 수 있으며, 최초 코드 공유 이후에 인터페이스가 나빠질 수도 있음 다른 공개 함수의 흔한 호출 조합으로 정의한 단축 API는 예외이며, 진정한 단축 경로를 유지하려면 오히려 비공개 함수를 호출하지 않아야 함 지침은 표준에 적혀 있다는 이유가 아니라 그 지침을 뒷받침하는 근거 때문에 적용해야 하며, 모범 사례도 개발자 자신의 판단을 대신하지 못함 공개 인터페이스와 공통 구현 분리 공개 함수 foo의 작업 일부를 다른 공개 함수 bar가 이미 처리한다면, DRY 원칙에 따라 foo에서 bar()를 호출하고 싶어질 수 있음 이 방식은 나중에 문제를 일으키는 경우가 많으므로, 비공개 헬퍼를 만들고 두 함수가 공통 헬퍼를 호출하도록 리팩터링하는 편을 권함 구체적인 사례 없이 제안하는 소규모 경험칙임 공개 API의 목표는 외부 호출 지점에서 가장 편리한 인터페이스를 제공하는 것임 공개 API 일부로 나머지 API를 구현하면, 외부 사용자에게 편리한 인터페이스와 추상화 내부에서 쓰기 편한 인터페이스 사이에 긴장이 생김 사용자가 설정해서는 안 되는 선택적 매개변수가 늘어날 수 있으며, 이런 매개변수 증가와 인터페이스 악화는 최초 코드 공유 이후에도 발생할 수 있음 공통 구현을 미리 비공개로 분리하면 이 충돌을 해소할 수 있음 필요한 기능을 모두 처리하도록 helper의 시그니처를 조정해야 할 수는 있지만, 비공개 함수이므로 비용이 적은 국소적 변경에 그침 단축 API는 다른 공개 함수를 흔히 쓰는 순서로 호출하도록 정의한 함수이므로 반대 규칙을 적용함 비공개 호출을 허용하지 않아야, 잘못 만들어진 중간 계층이 아니라 진정한 단축 API로 유지할 수 있음 테스트와 지침을 따르는 근거 관련 Stack Overflow 질문의 최다 추천 답변은 공개 함수 간 호출에 반대하며, 단일 메서드를 격리해 테스트하기 위한 모킹이 어려워진다는 점을 근거로 듦 반론으로는 메서드가 아니라 입출력(IO) 을 모킹하고, 메서드 단위보다 소프트웨어의 기능을 테스트해야 한다는 의견이 있음 안정적인 API를 제공하는 공개 라이브러...