CQS 원칙에 따르면 모든 방법은 작업을 수행하는 명령이거나 호출자에게 데이터를 반환하는 쿼리 중 하나 여야하며 둘 다가 아니어야합니다. 쿼리가 상태를 변경할 것으로 예상하지 않기 때문에 쿼리가 다른 작업을 수행하지 않는 것이 좋습니다. 그러나 Command가 여분의 정보를 반환하는지 여부는 무해합니다. 반환 된 값을 사용하거나 무시할 수 있습니다. CQS 원칙에 따라 값을 반환하지 않는 명령이 필요한 이유는 무엇입니까?CQS 원칙에 따라 값을 반환하지 않는 명령이 필요한 이유는 무엇입니까?
CQS의 이점 중 하나는 분산 환경에서 얼마나 잘 작동하는지에 대한 이해입니다. 명령은 즉시 실행되고, 나중에 실행될 대기열에 배치되고, 원격 이벤트 처리기 등이 실행하는 자체 격리 된 단위가됩니다.
리턴 키 유형을 지정하는 경우 커다란 영향을줍니다 CQS 패턴의 강도가 분산 모델 내에서 잘 맞는지 여부
이 문제 (see this article for instance by Mark Seemann)를 해결하는 일반적인 방법은 명령 처리기에서 실행 한 이벤트에 고유 한 guid와 같은 고유 ID를 생성하는 것입니다. 그런 다음 데이터를 나중에 식별 할 수 있도록 유지됩니다.
그러나 명령이 여분의 정보를 반환하면 무해한 것처럼 보입니까?
종종 있습니다. 때때로 그렇지 않습니다.
사람들은 명령에 대해 혼란스러운 쿼리를 시작하거나 명령이 반환하는 정보에 대해 명령을 혼란스럽게 시작할 수 있습니다 (실제 효과가되지 않도록하는 "영리한"방법과 함께).
인터페이스에서 갭을 유발할 수 있습니다. 유일한 유스 케이스 사람들이 특정 쿼리에 대해 상상할 수있는 경우 특정 명령과 함께 사용하면 쿼리의 순수한 형식을 추가하는 것은 의미가없는 것처럼 보일 수 있습니다 (예 : Pop()이 포함 된 스택 작성, Peek()이없는 스택 작성). 향후 변경에 대비하여 구성 요소의 유연성을 제한합니다.
"무해한 것처럼 보입니다"라는 말은 CQS가 그러한 구성을 금지함에있어 경고하는 것과 정확히 같습니다.
이제는 특정 명령 - 쿼리 조합이 그만한 가치가 있기에 유용하지 않다고 결정할 수는 없지만 그러한 결정의 찬반 양론에 무게를 두는 CQS는 항상 그것에 반대하는 목소리.