Là một chức năng nhận được một giá trị từ một chức năng khác được coi là thuần túy?

Tôi đang cố gắng tìm ra cách xử lý các giá trị biến mặc định khi tạo các hàm không có tác dụng phụ và đã kết thúc bằng các cách sau:

function getDefaultSeparator() {
    return ':';
}

function process(input, separator) {
    var separator = separator || getDefaultSeparator();

    // Use separator in some logic

    return output;
}

Dấu phân cách mặc định sẽ được sử dụng trong các chức năng khác và tôi chỉ muốn xác định nó ở một nơi.

Nếu đây là một hàm thuần túy, sự khác biệt so với việc chỉ sử dụng hằng số DEFAULT_SEPARATOR toàn cầu thay thế là gì?

Là một chức năng nhận được một giá trị từ một chức năng khác được coi là thuần túy?

Điều đó phụ thuộc vào chức năng khác làm gì và chức năng gọi làm gì. Tạp chất là truyền nhiễm, tinh khiết không.

Gọi một hàm thuần túy không làm thay đổi độ tinh khiết của hàm gọi. Gọi một chức năng không tinh khiết cũng làm cho chức năng gọi không tinh khiết.

Vì vậy, trong ví dụ của bạn, nó phụ thuộc vào độ tinh khiết của phần bạn bỏ đi: nếu đó là thuần túy, thì toàn bộ hàm là thuần túy.

Nếu đây là một hàm thuần túy, sự khác biệt so với việc chỉ sử dụng hằng số DEFAULT_SEPARATOR toàn cầu thay thế là gì?

Không có gì. Một hàm luôn trả về cùng một giá trị không thể phân biệt với hằng số. Trong thực tế, đó chính xác là cách các hằng số được mô hình hóa trong calcul-tính toán.

Vâng, đó là cả hai hàm thuần túy (giả sử phần elined cũng là thuần túy) bởi vì:

1. Kết quả chỉ phụ thuộc vào các tham số.
2. Không có tác dụng phụ.

Lưu ý rằng nếu getDefaultSeparator()không phải là một hàm thuần túy thì cả hai sẽ không process()thuần.

Trong Javascript, không có sự khác biệt có ý nghĩa giữa việc sử dụng hàm thuần túy hoặc hằng số và cả hai đều có thể được sử dụng bởi hàm thuần túy, miễn là khả năng của Javascript xác định lại các hàm hoặc thay đổi giá trị của hằng số.

Một khái niệm chính đằng sau các hàm thuần túy là chúng có thể được thay thế bằng giá trị mà chúng trả về mà không ảnh hưởng đến kết quả của chương trình.

Như những người khác đang nói, chắc chắn, nó vẫn là một chức năng thuần túy.

Tuy nhiên, hãy nói về các vấn đề thiết kế. Bạn có quyền thử làm một cái gì đó để giữ mã DRY, bằng cách đặt giá trị ở một nơi duy nhất. Ngoài ra, điều tôi nghĩ cũng nên được xem xét là mức độ khớp nối phù hợp.

Sử dụng một chức năng cho phép bạn linh hoạt hơn để thay đổi việc thực hiện, điều đó có nghĩa là cách tiếp cận chức năng cung cấp khớp nối lỏng lẻo hơn một biến toàn cục.

Câu hỏi là liệu người ta có cần nó hay không?

Nếu người tiêu dùng và nhà cung cấp ở trong cùng một mô-đun và nhà cung cấp là riêng tư đối với mô-đun, thì khó có thể tranh luận rằng mức độ khớp nối lỏng lẻo này là cần thiết, do thực tế là nếu nhà cung cấp yêu cầu nâng cấp từ một biến riêng tư thành một Phương pháp riêng tư, tái cấu trúc đơn giản trong mô-đun có thể được áp dụng cho người tiêu dùng cùng một lúc. Sử dụng một phương thức / chức năng trước khi bạn thực sự cần có thể thuộc YAGNI.

Ngay cả khi người tiêu dùng và nhà cung cấp ở các mô-đun khác nhau, nhưng các mô-đun được phiên bản cùng nhau (ví dụ: bạn sử dụng một công cụ khai thác để các mô-đun của người tiêu dùng và nhà cung cấp nằm trong cùng một tệp), YAGNI cũng có thể áp dụng.

Mặt khác, ví dụ, nếu nhà sản xuất ở trong thư viện hoặc gói API hoặc mô-đun được phiên bản riêng biệt với (các) người tiêu dùng, thì việc sử dụng chức năng có thể phù hợp. Trong trường hợp đó, chúng ta nên xem xét tuổi thọ của API và các nguyên tắc như OCP.

(Một lưu ý khác, nếu mã của bạn có kích thước đáng kể, tôi sẽ khuyến khích sử dụng các mô-đun với các trường và phương thức thay vì các biến và hàm toàn cục.)