Nguồn gốc của một phương thức nên trả về một giá trị hoặc có tác dụng phụ, nhưng không phải cả hai

Tôi đã đọc một lần rằng một phương thức nên có giá trị trả về (và được minh bạch tham chiếu) hoặc có (các) hiệu ứng phụ, nhưng không phải cả hai. Tôi không thể tìm thấy bất kỳ tài liệu tham khảo nào cho quy tắc này, nhưng muốn tìm hiểu thêm về nó.

Nguồn gốc của lời khuyên này là gì? Trong số những người hoặc cộng đồng đã làm nó phát sinh?

Tín dụng bổ sung: lợi ích được yêu cầu của việc làm theo lời khuyên này là gì?

Theo Greg Young, ý tưởng này bắt nguồn từ Bertrand Meyer : Phân tách truy vấn lệnh .

Nó tuyên bố rằng mọi phương thức nên là một lệnh thực hiện một hành động hoặc một truy vấn trả về dữ liệu cho người gọi, nhưng không phải cả hai. Nói cách khác, Đặt câu hỏi không nên thay đổi câu trả lời . ¹ Chính thức hơn, các phương thức chỉ trả về một giá trị nếu chúng trong suốt được tham chiếu và do đó không có tác dụng phụ.

1: Eiffel: một ngôn ngữ cho slide kỹ thuật phần mềm 43-48

Trong Thiết kế hướng tên miền, điều này tương tự như Phân tách / Phân tách đọc-truy vấn đọc lệnh (CQRS), như được đặt tên bởi Greg Young.

Greg Young đã lấy ý tưởng về CQS từ Bertrand để đặt tên cho CQRS như được đề cập bởi Martin Fowler trong bài viết về CQRS này

Những lợi ích

• Phần Đọc (Truy vấn) có thể được thu nhỏ / điều chỉnh khác với phần Viết (lệnh). Việc tách hai cái sẽ ngăn không cho nhau cản trở nhau khi tối ưu hóa / hiệu suất là chìa khóa.

Đọc bài viết trong liên kết Martin Fowler để biết thêm.

Tôi không biết nó đến từ đâu, nhưng đó là lời khuyên tốt và khá dễ hiểu.

Bất kỳ chương trình được thiết kế hoàn toàn sẽ được chia thành nhiều phần khác nhau, được kết hợp và sáng tác theo nhiều cách khác nhau. Càng khó để lý giải về bất kỳ phần cụ thể nào, thì càng khó để đảm bảo rằng chương trình của bạn sẽ phản ứng theo cách có thể dự đoán được.

Cô lập các bộ phận tạo ra tác dụng phụ làm cho phần còn lại dễ dàng lý luận, kiểm tra và gỡ lỗi. Giảm số lượng tác dụng phụ trong mỗi phần tạo ra hiệu ứng phụ sẽ giúp phần đó dễ dàng hoạt động hơn theo cách tương tự.

Nếu bạn phân tách nó hơn nữa, giá trị trả về là một hiệu ứng. Tác dụng phụ là một hiệu ứng. Một hàm chỉ nên tạo ra 1 hiệu ứng (nếu có thể) bởi vì số lượng đầu vào và hiệu ứng của hàm càng nhiều thì càng khó khăn trong việc suy luận về những gì nó thực sự làm.

Tín dụng bổ sung: lợi ích được tuyên bố ban đầu của việc làm theo lời khuyên này là gì?

Một trong những lợi ích của việc tách giá trị trả về khỏi các tác dụng phụ là nó loại bỏ một vấn đề tiềm ẩn có thể gây ra do đánh giá ngắn mạch .

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
}