교차 절단 우려 예
답변:
이해하기 전에 크로스 커팅 관심사를 , 우리는 이해해야 우려를 .
우려 기능에 기초하여 분할 시스템의 부분을 지칭하는 용어이다.
우려 사항은 두 가지 유형입니다.
- 기본 요구 사항에 대한 단일 및 특정 기능을 나타내는 문제를 핵심 문제라고 합니다.
또는
시스템의 주요 기능은 핵심 관심사로 알고 있습니다.
예 : 비즈니스 로직 - 2 차 요구 사항에 대한 기능을 나타내는 문제를 교차 문제 또는 시스템 전체 문제라고 합니다.
또는 크로스 커팅 문제는 응용 프로그램 전체에 적용 할 수있는 문제이며, 그것은 전체 응용 프로그램에 영향을 미칩니다. 예를 들어 , 로깅, 보안 및 데이터 전송은 애플리케이션의 거의 모든 모듈에서 필요한 문제이므로 교차 문제입니다.
이 그림은 모듈로 분류 된 일반적인 애플리케이션을 나타냅니다. 각 모듈의 주요 관심사는 특정 도메인에 대한 서비스를 제공하는 것입니다. 그러나 이러한 각 모듈에는 보안 로깅 및 트랜잭션 관리와 같은 유사한 보조 기능도 필요합니다. 크로스 커팅 문제의 예로는 "로깅"이 있으며, 이는 메서드 호출을 추적하여 디버깅을 지원하기 위해 분산 응용 프로그램에서 자주 사용됩니다. 각 함수 본문의 시작과 끝에서 로깅을 수행한다고 가정합니다. 이것은 적어도 하나의 기능을 가진 모든 클래스를 크로스 커팅하게됩니다.
교차 절단 우려의 가장 좋은 예는 거래 행동이라고 생각합니다. 예를 들어 모든 서비스 메서드에 커밋 및 롤백 호출과 함께 try-catch 블록을 넣어야하는 것은 기피 할 수 있습니다. AOP가 원하는 트랜잭션 동작으로 캡슐화하는 데 사용할 수있는 마커로 메서드에 주석을 추가하면 큰 이점이 있습니다.
교차 절단 우려의 예로서 또 다른 좋은 후보는 승인입니다. 누가 호출 할 수 있는지 알려주는 마커로 서비스 메소드에 주석을 달고 AOP 조언이 메소드 호출을 허용할지 여부를 결정하도록하는 것이 서비스 메소드 코드에서 처리하는 것보다 나을 수 있습니다.
AOP 어드바이스로 로깅을 구현하면 더 많은 유연성을 얻을 수 있으므로 결합 지점을 변경하여 로깅되는 내용을 변경할 수 있습니다. 실제로 나는 그렇게 자주하는 프로젝트를 보지 못합니다. 일반적으로 필요한 경우 런타임에 로깅 수준 및 범주별로 필터링 할 수있는 log4j와 같은 라이브러리를 사용하면 충분히 잘 작동합니다.
핵심 관심사는 애플리케이션이 존재하는 이유, 애플리케이션이 자동화하는 비즈니스 로직입니다. 운송화물을 처리하는 물류 애플리케이션이있는 경우, 트럭에 얼마나 많은화물을 포장 할 수 있는지 또는 트럭이 배송 물을 내리기 위해 가져갈 가장 좋은 경로가 무엇인지 파악하는 것이 핵심 관심사 일 수 있습니다. 교차 우려 사항은 일반적으로 비즈니스 로직과 별도로 유지해야하는 구현 세부 사항입니다.
받아 들여지는 답변 외에도 교차 문제에 대한 또 다른 예를 언급하고 싶습니다. 마치 프로세스에서 실행중인 것처럼 내 생태계의 다른 구성 요소를 로컬로 호출하고 싶다고 가정 해 보겠습니다. 어쩌면 어떤 경우에는 그렇게 할 수도 있습니다. 하지만 이제는 클라우드 또는 클러스터에 배포 된 서비스를 실행하고 싶습니다. 애플리케이션 개발자로서이 측면에 관심을 가져야하는 이유는 무엇입니까? 한 측면은 필요한 경우 전송 된 데이터를 직렬화하고 원격 호출을 수행하여 누구에게 어떻게 전화를해야하는지 알아낼 수 있습니다. 모든 것이 프로세스에서 실행 중이면 aspect는 로컬 호출을 전달합니다. 수신자 측에서 aspect는 데이터를 역 직렬화하고 로컬 호출을 수행하고 결과를 반환합니다.
이제 로그 출력과 같은 "사소한"것들에 대한 작은 이야기를 들려 드리겠습니다. 몇 주 전에 클라이언트를 위해 복잡하지만 너무 큰 코드베이스 (약 25 만 줄의 코드)를 리팩토링했습니다. 수백 개의 클래스에서 한 종류의 로깅 프레임 워크가 사용되었고 또 다른 수백 개에서 사용되었습니다. 그런 다음 수천 줄이System.out.println(*)로그 출력이 있어야하는 곳입니다. 그래서 코드베이스 전체에 흩어져있는 수천 줄의 코드를 수정했습니다. 다행히도 전체 작업 속도를 높이기 위해 IntelliJ IDEA (구조 검색 및 교체)에서 몇 가지 영리한 트릭을 사용할 수 있지만, 사소하다고 생각하지 마세요! 물론, 강력한 컨텍스트 의존적 디버그 로깅은 항상 메서드 본문 내에서 발생하지만 메서드 호출 추적 (잘 들여 쓰기 된 출력이있는 계층 적), 처리되거나 처리되지 않은 예외 모두 로깅, 사용자 감사 (로깅 호출)와 같은 많은 중요한 로깅 유형이 있습니다. 사용자 역할에 따라 제한된 메서드) 등은 소스 코드를 오염시키지 않고 측면에서 쉽게 구현할 수 있습니다. 일상적인 응용 프로그램 개발자는 그것에 대해 생각할 필요가 없으며 코드베이스에 흩어져있는 로거 호출을 볼 필요도 없습니다.
다른 교차 문제에 대해 비슷한 설명을 할 수 있습니다. 코드를 깨끗하게 유지하고 IMO를 산란 및 얽 히지 않도록 유지하는 것은 선택 사항이 아니라 전문성의 문제입니다. 마지막으로 코드를 읽기 쉽고 유지 보수 가능하며 리팩토링 가능하게 유지합니다. 아멘.
교차 절단 우려는 애플리케이션 유형에 관계없이 항상 존재해야하는 시나리오입니다.
예를 들어 로깅, 보안, 성능 프로파일 링, 현지화, 접근성, 트랜잭션 등. 우리가 구축하는 소프트웨어에 관계없이 로깅이 필요합니다 (그렇지 않으면 일부 사용자가 제품 데이터에서 관련 정보를 디버깅하거나 가져 오는 방법). 보안 (인증 / 승인 등)은 인증 된 사용자 만 권한 집합으로 애플리케이션에 진입 할 수있는 곳에 필요합니다. 애플리케이션의 성능을 파악하고 프로파일 링을 수행해야합니다. 해외 사용자 (자신의 현지화 언어)가 응용 프로그램을 사용하는 경우 응용 프로그램에서 동일하게 지원해야합니다. 접근성은 장애인이 애플리케이션을 사용할 수있는 사용성 사례입니다.
이제 우리의 애플리케이션이 데스크톱 기반인지 웹 기반인지에 관계없이 프로덕션 환경의 여러 지역에서 최종 사용자가 사용해야하는 경우 교차 컷이 필요합니다. 지금까지 나는 응용 프로그램이 무엇인지 등에 대해 언급하지 않았지만 프로덕션 환경에서 최종 사용자에게 릴리스하기 전에 해결해야 할 우려 사항 목록을 제공했습니다. 그리고 그것은 크로스 컷 문제에 관한 것입니다 (모든 애플리케이션 / 메소드 / 클래스, 즉 다양한 수준에서 처리되어야 함).