핸들러 - 작은 구현이 좋은 이유는 무엇입니까?

컨트롤러, 마우스 이벤트 리스너, 메시지 소비자 및 유사한 엔티티는 핸들러 유형입니다. 핸들러는 단순히 입력을 받아들이고, 가능한 경우 수신된 입력 데이터로 진행할지 선택적으로 결정하고, 입력을 적절한 형식으로 변환하고, 기본 프로시저를 호출합니다.

여기서 주요 질문은 핸들러가 얼마나 커질 수 있는지, 핸들러에 어떤 종류의 논리가 포함될 수 있는지입니다.

핸들러가 무엇을 할 수 있는지 설명하겠습니다.

소프트웨어 애플리케이션 및 핸들러

소프트웨어 응용 프로그램은 특정 작업을 수행하도록 설계된 컴퓨터 프로그램입니다. 사용자/클라이언트는 사용자 인터페이스나 REST, 메시지 대기열 등과 같은 네트워크 호출을 통해 애플리케이션과 통신할 수 있습니다. 따라서 각 애플리케이션에는 사용자/클라이언트의 입력 수락, 입력 확인, 응용 프로그램 내부의 특정 절차를 수행하고 마지막으로 출력을 반환합니다. 일반적으로 해당 계층을 핸들러라고 합니다. 핸들러는 일련의 끝점, 키보드 또는 마우스 이벤트 리스너, 메시지 대기열의 소비자, 명령줄 인수의 파서 등이 있는 REST 컨트롤러일 수 있습니다.

처리기의 주요 역할은 입력 데이터를 수락 및 유효성 검사하고, 프로시저 호출을 위해 입력에서 데이터를 준비하고, 가능한 경우 진행 여부를 결정하고, 프로시저를 호출하고, 프로시저 호출 결과가 있는 경우 반환하는 것입니다.

따라서 핸들러의 역할은 일반적으로 여러 라이브러리로 구성된 애플리케이션과 통신하는 방법을 제공하는 것입니다. 기술적으로 사용자/클라이언트에게 애플리케이션과 통신하기 위해 다른 인터페이스를 다른 방식으로 제공하는 것은 어렵지 않습니다.

애플리케이션이 REST 또는 SOAP, Protobuf 인터페이스 또는 동일한 절차를 호출하는 것과 유사한 것을 노출하는 경우 매우 유사해야 합니다. 해당 처리기는 입력 데이터를 받아들이고 프로시저에 필요한 입력을 준비하고 프로시저를 호출합니다.

| Handlers                             | Procedures               |
+--------------------------------------+--------------------------+
|                                      |                          |
+----------+                           |                          |
| REST     |-------+                   |                          |
+----------+       |                   |                          |
| Thrift   |-----+ |                   |                          |
+----------+     | |                   |                          |
| Protobuf |-----+-+------<-------->---| application's procedure  |
+----------+     | |     output/input  |                          |
|   ....   |-----+ |                   |                          |
+----------+       |                   |                          |
| RMI      |-------+                   |                          |
+----------+                           |                          |
|                                      |                          |
+--------------------------------------+--------------------------+
| Other Handlers                       | Other procedures         |
+--------------------------------------+--------------------------+

얼마나 많은 논리가 핸들러를 포함해야 합니까?

이 질문에 답하기 위해 우리는 몇 가지 측면을 고려할 것입니다.

OOP 설계의 단일 책임 원칙

테스트 가능성

아마도 "단일 책임 원칙"만 고려한다면 두 번째 측면도 이미 중복되었을 것입니다. 원리는 oodesign.com에 다음과 같이 설명되어 있습니다.

A responsibility is considered to be one reason to change. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes.

처리기가 입력 유효성 검사, 인증 유효성 검사, 프로시저 호출을 위한 다른 매개 변수 준비, 출력 변환을 포함하는 경우 이러한 구현은 분명히 "단일 책임 원칙"을 위반하는 것입니다. 핸들러에 명시적으로 속하지 않는 논리를 추상화 또는 입력 처리 체인으로 옮기는 것이 훨씬 낫습니다.

종속성이 많은 길고 복잡한 구현을 가진 핸들러를 테스트하는 것은 악몽입니다 :) 테스트 주도 개발을 사용하고 "단일 책임"원칙을 염두에 두는 것은 테스트하기 쉽고 OOP 디자인 패턴을 준수하는 충분히 작은 것을 만드는 데 도움이 됩니다. .

이러한 아키텍처의 아주 좋은 예는 Spring Boot입니다. 인증을 처리하는 DTO 필터에 대한 특수 주석을 제공하고 컨텍스트에 필요한 모든 매개 변수를 처리기에서 쉽게 사용할 수 있는 요청 속성에 할당하여 유효성 검사를 수행할 수 있습니다. 유효성 검사 규칙은 단위 테스트의 대상이며 별도로 테스트할 수 있지만 핸들러 수준에서 원하는 유효성 검사 규칙이 적용되는지 확실히 확인해야 합니다.

핸들러는 테스트하기 쉬워집니다. 테스트해야 할 모든 것은 컨트롤러가 입력 데이터를 받아들이는 방법, 유효성 검사에 실패/성공하는 방법, 출력이 예상 형식을 준수하는지 여부입니다. 나머지는 단위 테스트와 마지막으로 통합 테스트에 의해 개별적으로 테스트됩니다.

결론

핸들러의 구현을 작게 유지하고 OOP 설계 원칙을 염두에 두고 구현을 작게 유지하고 테스트하기 쉽도록 선택적으로 테스트 기반 개발을 사용해 보십시오.