"방법은 값을 반환하거나 부작용을 가져야하지만 둘다는 안된다"

나는 메소드가 반환 값을 가져야하고 (참조 적으로 투명해야 함) 부작용을 가져야하지만 둘다는 안된다는 것을 한 번 읽었습니다. 이 규칙에 대한 언급은 찾을 수 없지만 더 자세히 알고 싶습니다.

이 조언의 기원은 무엇입니까? 어떤 사람이나 공동체에서 발생 했습니까?

추가 크레딧 :이 조언을 따르면 어떤 이점이 있습니까?

Greg Young에 따르면이 아이디어는 Bertrand Meyer : Command-Query 분리에서 시작되었습니다 .

모든 메소드는 조치를 수행하는 명령이거나 호출자에게 데이터를 리턴하는 쿼리 여야하지만 둘다는 아니라고 명시합니다. 다시 말해, 질문을하면 대답이 바뀌지 않아야합니다 . ¹ 더 공식적으로, 메소드는 참조가 투명하고 부작용이없는 경우에만 값을 리턴해야합니다.

1 : 에펠 : 소프트웨어 엔지니어링 슬라이드 43-48 용 언어

도메인 기반 디자인에서 이는 Greg Young이 명명 한 CQRS (Command-Query-Read Separation / Segregation)와 유사합니다.

Greg Young은이 CQRS 기사 에서 Martin Fowler가 언급 한 것처럼 Bertrand의 CQS를 CQRS로 명명했습니다.

혜택

• 읽기 (쿼리) 부분은 쓰기 (명령) 부분과 다르게 스케일 / 조정될 수 있습니다. 둘을 분리하면 최적화 / 성능이 핵심 일 때 서로 방해가되지 않습니다.

자세한 내용은 Martin Fowler 링크 의 기사를 읽으십시오 .

나는 그것이 어디에서 왔는지 모르지만 좋은 조언이며 이해하기가 매우 간단합니다.

깔끔하게 디자인 된 프로그램은 여러 부분으로 나뉘어 다양한 방식으로 결합되어 구성됩니다. 특정 부분이 무엇을하는지 추론하기가 어려울수록 프로그램이 예측 가능한 방식으로 반응하도록하는 것이 더 어려워집니다.

부작용을 일으키는 부품을 분리하면 나머지를 쉽게 추론, 테스트 및 디버그 할 수 있습니다. 부작용을 발생시키는 각 부품의 부작용 수를 줄이면 동일한 방식으로 해당 부품을보다 쉽게 ​​사용할 수 있습니다.

더 분해하면 반환 값이 적용됩니다. 부작용은 효과입니다. 함수는 입력과 효과의 수가 많을수록 실제로 수행하는 작업을 추론하기가 어렵 기 때문에 함수는 1 개의 효과 만 발생해야합니다 (가능한 경우).

추가 크레딧 : 이 조언을 따를 때 원래 주장 된 이점은 무엇입니까 ?

부작용에서 리턴 값을 분리하는 것의 장점 중 하나는 단락 평가 로 인해 발생할 수있는 잠재적 인 문제를 제거한다는 것 입니다.

bool FooWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

bool BarWithSideEffect() {
    // do query
    // do side effect
    return resultOfQuery;
}

void BadShortCircuitEvaluation()
{
    // the programmer's intent is to have side effects of both functions
    if (FooWithSideEffect() && BarWithSideEffect() ) {
        // do something
    }

    // in case FooWithSideEffect() returns true, 
    // then BarWithSideEffect() is not called at all
    // because of short-circuit evaluation
}