Có một lý do tốt để làm cho các chức năng thuần túy không công khai?

Tôi đã có một cuộc tranh luận nhỏ với một đồng nghiệp. Nói một cách đơn giản, có lý do chính đáng để ẩn / đóng gói các hàm thuần túy không?

Theo "thuần" tôi có nghĩa là định nghĩa wikipedia :

• Luôn trả về cùng kết quả từ cùng một đầu vào. (Vì lợi ích của cuộc thảo luận Foo Create(){ return new Foo(); }này được coi là không trong sạch nếu Fookhông có ngữ nghĩa giá trị.)
• Không sử dụng trạng thái có thể thay đổi (ngoại trừ các biến cục bộ) hoặc I / O.
• Không tạo ra tác dụng phụ.

Một chức năng thuần túy vẫn có thể là một chi tiết thực hiện. Mặc dù chức năng có thể không gây hại (từ quan điểm không phá vỡ các bất biến / hợp đồng quan trọng), bằng cách làm cho cả tác giả và người dùng của lớp / mô-đun / gói đó bị mất. Tác giả thua vì bây giờ anh ta không thể xóa nó ngay cả khi việc triển khai thay đổi và chức năng không còn hữu ích với anh ta nữa. Người dùng mất vì họ phải chọn lọc và bỏ qua các chức năng bổ sung không liên quan đến việc sử dụng API để hiểu nó.

Câu hỏi ngược.

Bạn không tìm kiếm một lý do để làm cho một chức năng không công khai. Đó là một suy nghĩ không chính xác để bắt đầu (theo ý kiến ​​của tôi). Lý luận nên đi theo con đường khác.

Nói cách khác - đừng hỏi "tại sao tôi lại đặt nó ở chế độ riêng tư?". Hỏi: "tại sao tôi sẽ công khai nó?"

Khi nghi ngờ, đừng phơi bày nó. Nó giống như dao cạo của Ockham - không nhân lên nhiều quyền lợi cần thiết.

EDIT: Giải quyết các phản biện được đưa ra bởi @Telastyn trong các bình luận (để tránh thảo luận mở rộng ở đó):

Tôi đã nghe điều đó theo thời gian và thậm chí đã tán thành nó khá lâu, nhưng theo kinh nghiệm của tôi, mọi thứ có xu hướng quá riêng tư.

Có, đôi khi thật đau đớn nếu một lớp được mở để thừa kế, nhưng bạn không thể ghi đè một số phương thức riêng tư (hành vi mà bạn muốn thay đổi).

Nhưng protectedsẽ đủ - và nó vẫn không công khai.

Nó dẫn đến rất nhiều sự trùng lặp mã và chi phí để có được "những thứ không nên công khai" dù sao cũng được truy cập gián tiếp.

Nếu nó trở thành vấn đề, sau đó chỉ cần làm cho nó công khai! Có sự cần thiết tôi đã nói về :)

Quan điểm của tôi là bạn không nên làm điều đó trong trường hợp (YAGNI và tất cả).

Lưu ý rằng việc đặt chức năng riêng tư luôn dễ dàng hơn là kéo nó trở lại quyền riêng tư. Cái sau có khả năng phá vỡ mã hiện có.

Tôi không nghĩ rằng quyết định ẩn / đóng gói một chức năng nên phụ thuộc vào độ tinh khiết của nó. Chỉ vì một chức năng là thuần túy không có nghĩa là bên ngoài cần biết về nó. Thật thú vị mặc dù nếu chức năng này là thuần túy và có nghĩa là công khai thì có lẽ nó thậm chí không cần phải là một thành viên của giao diện, có lẽ nó phù hợp hơn như là một tĩnh. Nhưng một lần nữa tất cả những điều này phụ thuộc vào mục đích của hợp đồng và trong trường hợp này là nhóm hợp lý của chức năng, chứ không phải độ tinh khiết của chức năng.

Các lớp học phải tuân thủ Nguyên tắc Trách nhiệm duy nhất . Mặc dù một lớp có thể cần phải gọi các chức năng khác để đạt được các mục tiêu của mình, nhưng nó chỉ nên phơi bày các chức năng là một phần của trách nhiệm duy nhất của nó.

Đây chỉ là một ví dụ về trường hợp khả năng hiển thị có thể gây ra vấn đề.

Hãy xem xét một lớp mà frobnicates widget. Có thể là một phần của mã frobnication của nó, nó cần một số hàm tiện ích để phân tích một chuỗi: có lẽ nó cần phải chuyển đổi tên widget theo cách mà các hàm chuỗi tiêu chuẩn không hỗ trợ.

Vì đây là một hàm thuần túy (chuỗi đi vào, chuyển đổi nó bằng cách nào đó, trả về một chuỗi mới), nó có thể là công khai hoặc riêng tư mà không có hậu quả. Hay nó có thể?

Nếu bạn đặt nó ở chế độ công khai, bây giờ lớp của bạn có hai trách nhiệm: các tiện ích frobnicating và chuyển đổi chuỗi. Điều này vi phạm SRP và có thể gây ra vấn đề nếu các lớp khác dựa vào chức năng. Vì đây là thứ bạn nghĩ chỉ được sử dụng nội bộ cho lớp, nên có lẽ bạn thay đổi giao diện hoặc mức độ hiển thị của nó. Bây giờ các lớp trong các phần khác của hệ thống bị hỏng.

Bằng cách giữ chức năng riêng tư, không ai có cơ hội dựa vào mã không thuộc trách nhiệm duy nhất của lớp.