Những lợi ích của tính minh bạch tham chiếu cho một lập trình viên là gì?

Trong lập trình, những lợi ích của tính minh bạch tham chiếu là gì?

RT tạo ra một trong những khác biệt chính giữa các mô hình chức năng và mệnh lệnh, và thường được sử dụng bởi những người ủng hộ mô hình chức năng như một lợi thế rõ ràng so với mô hình mệnh lệnh; nhưng trong tất cả những nỗ lực của họ, những người ủng hộ này không bao giờ giải thích tại sao nó là một lợi ích cho tôi với tư cách là một lập trình viên .

Chắc chắn, họ sẽ có những giải thích học thuật về mức độ "thuần khiết" và "thanh lịch" của nó, nhưng làm thế nào để nó làm cho nó tốt hơn một mã "thuần túy" hơn? Làm thế nào nó có lợi cho tôi trong lập trình hàng ngày của tôi?

Lưu ý: Đây không phải là bản sao của tính minh bạch tham chiếu là gì? Câu hỏi sau đề cập đến chủ đề RT là gì , trong khi câu hỏi này nhấn mạnh lợi ích của nó (có thể không trực quan như vậy).

Lợi ích là các hàm thuần làm cho mã của bạn dễ dàng lý luận hơn. Hay nói cách khác, tác dụng phụ làm tăng độ phức tạp của mã của bạn.

Lấy một ví dụ về computeProductPricephương pháp.

Một phương thức thuần túy sẽ hỏi bạn về số lượng sản phẩm, một loại tiền tệ, v.v. Bạn biết rằng bất cứ khi nào phương thức được gọi với cùng một đối số, nó sẽ luôn tạo ra kết quả tương tự.

• Bạn thậm chí có thể lưu trữ nó và sử dụng phiên bản lưu trữ.
• Bạn có thể làm cho nó lười biếng và hoãn cuộc gọi của nó khi bạn thực sự cần nó, biết rằng giá trị sẽ không thay đổi trong khi đó.
• Bạn có thể gọi phương thức nhiều lần, biết rằng nó sẽ không có tác dụng phụ.
• Bạn có thể suy luận về chính phương thức này trong sự cô lập với thế giới, biết rằng tất cả những gì nó cần là các đối số.

Một phương thức không thuần túy sẽ phức tạp hơn để sử dụng và gỡ lỗi. Vì nó phụ thuộc vào trạng thái của các biến khác với các đối số và có thể thay đổi chúng, điều đó có nghĩa là nó có thể tạo ra các kết quả khác nhau khi được gọi nhiều lần hoặc không có cùng một hành vi khi không được gọi hoặc quá sớm hoặc quá muộn.

Thí dụ

Hãy tưởng tượng có một phương thức trong khung phân tích một số:

decimal math.parse(string t)

Nó không có tính minh bạch tham chiếu, bởi vì nó phụ thuộc vào:

• Biến môi trường chỉ định hệ thống đánh số, đó là Cơ sở 10 hoặc một cái gì đó khác.

• Biến trong maththư viện chỉ định độ chính xác của các số cần phân tích. Vì vậy, với giá trị của 1, phân tích chuỗi "12.3456"sẽ cung cấp 12.3.

• Văn hóa, trong đó xác định định dạng dự kiến. Ví dụ, với fr-FR, phân tích cú pháp "12.345"sẽ cung cấp 12345, bởi vì ký tự phân tách nên ,, không phải.

Hãy tưởng tượng sẽ dễ dàng hay khó khăn như thế nào khi làm việc với phương pháp như vậy. Với cùng một đầu vào, bạn có thể có các kết quả hoàn toàn khác nhau tùy thuộc vào thời điểm bạn gọi phương thức, bởi vì một cái gì đó, ở đâu đó đã thay đổi biến môi trường hoặc chuyển văn hóa hoặc đặt độ chính xác khác. Đặc tính không xác định của phương pháp sẽ dẫn đến nhiều lỗi hơn và ác mộng gỡ lỗi nhiều hơn. Gọi math.parse("12345")và nhận 5349như một câu trả lời vì một số mã song song đang phân tích số bát phân không tốt.

Làm thế nào để khắc phục phương pháp rõ ràng bị hỏng này? Bằng cách giới thiệu minh bạch tham chiếu. Nói cách khác, bằng cách loại bỏ trạng thái toàn cầu và di chuyển mọi thứ đến các tham số của phương thức:

decimal math.parse(string t, base=10, precision=20, culture=cultures.en_us)

Bây giờ phương thức này là thuần túy, bạn biết rằng bất kể khi bạn gọi phương thức, nó sẽ luôn tạo ra kết quả tương tự cho cùng một đối số.

Bạn có thường thêm điểm dừng vào một điểm trong mã của mình và chạy ứng dụng trong trình gỡ lỗi để tìm ra điều gì đang xảy ra không? Nếu bạn làm như vậy, phần lớn là do bạn không sử dụng độ trong suốt tham chiếu (RT) trong các thiết kế của mình. Và vì vậy phải chạy mã để tìm ra những gì nó làm.

Toàn bộ vấn đề đối với RT là mã có tính quyết định cao, tức là bạn có thể đọc mã và tìm ra những gì nó làm, mọi lúc, cho cùng một bộ đầu vào. Khi bạn bắt đầu thêm các biến đột biến, một số biến có phạm vi ngoài một hàm duy nhất, bạn không thể chỉ đọc mã. Mã như vậy phải được thực thi, trong đầu của bạn hoặc trong trình gỡ lỗi, để tìm ra cách nó thực sự hoạt động.

Mã càng đơn giản để đọc và suy luận, thì càng đơn giản để duy trì và phát hiện ra các lỗi, vì vậy nó giúp tiết kiệm thời gian và tiền bạc cho bạn và chủ nhân của bạn.

Mọi người vứt bỏ thuật ngữ "dễ lý luận hơn", nhưng không bao giờ giải thích điều đó có nghĩa là gì. Hãy xem xét ví dụ sau:

result1 = foo("bar", 12)
// 100 lines of code
result2 = foo("bar", 12)

Là result1và result2giống hay khác nhau? Không có tính minh bạch tham chiếu, bạn không có ý tưởng. Bạn phải thực sự đọc phần thân của foođể đảm bảo, và có thể phần thân của bất kỳ hàm nào foogọi, v.v.

Mọi người không nhận thấy gánh nặng này bởi vì họ đã quen với nó, nhưng nếu bạn làm việc trong một môi trường hoàn toàn hoạt động trong một hoặc hai tháng thì quay lại bạn sẽ cảm thấy nó, và đó là một vấn đề rất lớn .

Có rất nhiều cơ chế bảo vệ mà mọi người làm để giải quyết vấn đề thiếu minh bạch tham chiếu. Ví dụ nhỏ của tôi, tôi có thể muốn giữ result1lại trong bộ nhớ, vì tôi không biết liệu nó có thay đổi hay không. Sau đó, tôi có mã với hai trạng thái: trước result1được lưu trữ và sau. Với tính minh bạch tham chiếu, tôi chỉ có thể tính toán lại một cách dễ dàng, miễn là việc tính toán lại không tốn thời gian.

Tôi muốn nói: tính minh bạch tham chiếu không chỉ tốt cho lập trình chức năng mà còn cho tất cả những người làm việc với các chức năng vì nó tuân theo nguyên tắc ít gây ngạc nhiên nhất.

Bạn có một chức năng và có thể lý do tốt hơn về những gì nó làm bởi vì không có yếu tố bên ngoài nào bạn cần tính đến, đối với một đầu vào nhất định, đầu ra sẽ luôn giống nhau. Ngay cả trong ngôn ngữ bắt buộc của tôi, tôi cố gắng tuân theo mô hình này càng nhiều càng tốt, điều tiếp theo về cơ bản tự động theo sau là: các hàm nhỏ dễ hiểu thay vì các hàm 1000+ khủng khiếp mà tôi đôi khi chạy.

Những chức năng lớn đó làm nên điều kỳ diệu và tôi sợ chạm vào chúng vì chúng có thể phá vỡ một cách ngoạn mục.

Vì vậy, các hàm thuần túy không phải là thứ chỉ dành cho lập trình hàm, mà là cho mọi chương trình.