협력 객체가 많아져 생성·종료 순서가 복잡합니다. composition root는 어떤 의존성과 수명을 소유하나요?
꼬리 질문을 독립 문항으로 확장했습니다. 원래 문항에서 맥락 보기 →
잠깐, 답변을 보기 전에
먼저 내 말로 설명해 볼까요?
답변과 점검 포인트 펼치기답변 접기
01
구두 답변
정의를 외우기보다, 원리와 조건을 연결해 설명해 보세요.
composition root는 구체 구현을 조립하고 공유·요청별 자원의 수명과 종료 순서를 정하는 제한된 위치입니다. 정책 코드가 service locator로 전역 구현을 다시 찾게 하면 의존성이 숨습니다.
DB·HTTP pool·logger의 owner를 하나로 두고 사용 작업을 먼저 정리한 뒤 자원을 닫습니다. 생성 중 일부 실패하면 이미 만든 자원만 회수합니다. 테스트는 새 객체 그래프를 만들어 전역 상태 누수를 줄입니다.
02
득점 포인트
이해가 드러나는 지점을 확인해 보세요.
- composition root는 구체 구현을 조립하고 공유·요청별 자원의 수명과 종료 순서를 정하는 제한된 위치입니다. 정책 코드가 service locator로 전역 구현을 다시 찾게 하면 의존성이 숨습니다.
- 테스트는 새 객체 그래프를 만들어 전역 상태 누수를 줄입니다.
03
감점 포인트
놓치기 쉬운 조건과 오해를 짚어 보세요.
- 다음 핵심 구분을 반대로 설명하거나 성립 조건을 생략한다: composition root는 구체 구현을 조립하고 공유·요청별 자원의 수명과 종료 순서를 정하는 제한된 위치입니다.
04
더 파고들 거리
하나 더 질문하며 이해의 범위를 넓혀 보세요.
득점·감점 포인트는 학습용 자기 점검 기준이며, 특정 회사의 실제 채점표가 아닙니다.
원리부터 공부하고 싶다면
답변을 보충하는 개념·예제·슈도코드를 읽어 보세요.