Kilian Foth의 답변을 확장 하면서이 레이어링 방향은 인간이 시스템을 탐색하는 방향에 해당합니다.
계층화 된 시스템의 버그를 수정하는 새로운 개발자라고 가정 해보십시오.
버그는 일반적으로 고객의 요구와 얻는 것과의 불일치입니다. 고객이 UI를 통해 시스템과 통신하고 UI (문자 그대로 '사용자 인터페이스'를 의미 함)를 통해 결과를 얻으면 버그도 UI 측면에서보고됩니다. 따라서 개발자는 선택의 여지가 없으며 UI를 살펴보고 어떤 일이 발생했는지 파악할 수 있습니다.
이것이 하향식 레이어 연결이 필요한 이유입니다. 이제 연결이 양방향으로 진행되지 않는 이유는 무엇입니까?
글쎄, 당신은 그 버그가 어떻게 발생할 수 있는지 세 가지 시나리오를 가지고 있습니다.
UI 코드 자체에서 발생할 수 있으므로 현지화 될 수 있습니다. 이것은 쉽습니다. 장소를 찾아서 고치면됩니다.
UI에서 호출 한 결과 시스템의 다른 부분에서 발생할 수 있습니다. 어느 정도 어려운 것은 호출 트리를 추적하고 오류가 발생한 장소를 찾아 수정합니다.
UI 코드를 호출 한 결과 발생할 수 있습니다. 어려운 점은 전화를 잡고 소스를 찾은 다음 오류가 발생하는 위치를 찾아야합니다. 시작 지점이 호출 트리의 단일 브랜치에 깊숙이 위치하고 있고 올바른 호출 트리를 먼저 찾아야한다고 생각하면 UI 코드에 여러 호출이있을 수 있으므로 디버깅이 중단됩니다.
가장 어려운 경우를 최대한 제거하기 위해 순환 종속성은 권장하지 않으며 레이어는 대부분 하향식으로 연결됩니다. 다른 방법으로 연결해야하는 경우에도 일반적으로 제한되고 명확하게 정의됩니다. 예를 들어, 콜백이 일종의 역방향 연결 인 경우에도 콜백에서 호출되는 코드는 일반적으로이 콜백을 먼저 제공하여 역방향 연결을위한 일종의 "선택"을 구현하고 체계.
레이어링은 도구이며 주로 기존 시스템을 지원하는 개발자를 대상으로합니다. 레이어 간의 연결도이를 반영합니다.