Truy cập mặc định không làm cho bộ điều chỉnh truy cập riêng dự phòng.
Vị trí của các nhà thiết kế ngôn ngữ được phản ánh trong hướng dẫn chính thức - Kiểm soát quyền truy cập vào các thành viên của một lớp và nó khá rõ ràng (để thuận tiện cho bạn, tuyên bố có liên quan trong trích dẫn được in đậm ):
Mẹo về cách chọn cấp độ truy cập:
Nếu các lập trình viên khác sử dụng lớp của bạn, bạn muốn đảm bảo rằng lỗi từ việc sử dụng sai có thể xảy ra. Cấp độ truy cập có thể giúp bạn làm điều này.
- Sử dụng cấp độ truy cập hạn chế nhất có ý nghĩa đối với một thành viên cụ thể. Sử dụng riêng tư trừ khi bạn có một lý do tốt để không.
- Tránh các lĩnh vực công cộng trừ các hằng số. (Nhiều ví dụ trong hướng dẫn sử dụng các trường công khai. Điều này có thể giúp minh họa một số điểm chính xác, nhưng không được khuyến nghị cho mã sản xuất.) Các trường công khai có xu hướng liên kết bạn với một triển khai cụ thể và hạn chế tính linh hoạt của bạn trong việc thay đổi mã.
Sự hấp dẫn của bạn đối với khả năng kiểm tra vì sự biện minh cho việc bỏ hoàn toàn công cụ sửa đổi riêng tư là sai, bằng chứng là các câu trả lời trong Mới đối với TDD. Tôi có nên tránh các phương pháp riêng tư bây giờ?
Tất nhiên bạn có thể có các phương thức riêng tư, và tất nhiên bạn có thể kiểm tra chúng.
Có một số cách để chạy phương thức riêng tư, trong trường hợp đó bạn có thể kiểm tra theo cách đó hoặc không có cách nào để chạy riêng tư, trong trường hợp đó: tại sao bạn lại cố gắng kiểm tra nó, chỉ là xóa cái thứ chết tiệt đó đi ...
Vị trí của các nhà thiết kế ngôn ngữ về mục đích và cách sử dụng truy cập cấp gói được giải thích trong một hướng dẫn chính thức khác, Tạo và sử dụng các gói và nó không có gì chung với ý tưởng bỏ các sửa đổi riêng tư (để thuận tiện cho bạn, tuyên bố có liên quan trong trích dẫn được in đậm ) :
Bạn nên gói các lớp này và giao diện trong một gói vì nhiều lý do, bao gồm:
- Bạn và các lập trình viên khác có thể dễ dàng xác định rằng các loại này có liên quan ...
- Bạn có thể cho phép các loại trong gói có quyền truy cập không hạn chế đối với nhau nhưng vẫn hạn chế quyền truy cập đối với các loại bên ngoài gói ...
<rant "Tôi nghĩ rằng tôi đã nghe đủ tiếng rên rỉ. Đoán đến lúc phải nói to và rõ ràng ...">
Phương pháp riêng có lợi cho thử nghiệm đơn vị.
Lưu ý dưới đây giả định rằng bạn quen thuộc với phạm vi bảo hiểm mã . Nếu không, hãy dành thời gian để tìm hiểu, vì nó khá hữu ích cho những người quan tâm đến thử nghiệm đơn vị và thử nghiệm.
Được rồi, vì vậy tôi đã có các thử nghiệm đơn vị và phương pháp riêng tư và phân tích bảo hiểm cho tôi biết rằng có một khoảng cách, phương pháp riêng tư của tôi không được bao phủ bởi các thử nghiệm. Hiện nay...
Tôi có được gì khi giữ kín
Vì phương thức là riêng tư, cách duy nhất để tiến hành là nghiên cứu mã để tìm hiểu cách sử dụng nó thông qua API không riêng tư. Thông thường, một nghiên cứu như vậy cho thấy lý do của khoảng cách là kịch bản sử dụng cụ thể bị thiếu trong các thử nghiệm.
void nonPrivateMethod(boolean condition) {
if (condition) {
privateMethod();
}
// other code...
}
// unit tests don't invoke nonPrivateMethod(true)
// => privateMethod isn't covered.
Để hoàn thiện, các lý do khác (ít thường xuyên hơn) cho các khoảng trống bảo hiểm như vậy có thể là lỗi trong đặc tả / thiết kế. Tôi sẽ không đi sâu vào những điều này ở đây, để giữ cho mọi thứ đơn giản; đủ để nói rằng nếu bạn làm suy yếu giới hạn truy cập "chỉ để làm cho phương pháp có thể kiểm tra được", bạn sẽ bỏ lỡ cơ hội để biết rằng những lỗi này tồn tại.
Tốt thôi, để khắc phục khoảng trống, tôi thêm một bài kiểm tra đơn vị cho kịch bản bị thiếu, lặp lại phân tích bảo hiểm và xác minh rằng khoảng trống đã biến mất. Bây giờ tôi có gì? Tôi đã có bài kiểm tra đơn vị mới để sử dụng cụ thể API không riêng tư.
Thử nghiệm mới đảm bảo rằng hành vi dự kiến cho việc sử dụng này sẽ không thay đổi mà không có thông báo vì nếu thay đổi, thử nghiệm sẽ thất bại.
Một người đọc bên ngoài có thể xem xét bài kiểm tra này và tìm hiểu cách sử dụng và ứng xử (ở đây, người đọc bên ngoài bao gồm cả bản thân tương lai của tôi, vì tôi có xu hướng quên mã một hoặc hai tháng sau khi tôi hoàn thành nó).
Thử nghiệm mới có thể chấp nhận tái cấu trúc (tôi có cấu trúc lại các phương thức riêng tư không? Bạn đặt cược!) Dù tôi làm gì privateMethod, tôi sẽ luôn muốn thử nghiệm nonPrivateMethod(true). Bất kể tôi làm gì privateMethod, sẽ không cần sửa đổi kiểm tra vì phương thức không được gọi trực tiếp.
Không tệ? Bạn đặt cược.
Tôi mất gì khi làm suy yếu giới hạn truy cập
Bây giờ hãy tưởng tượng rằng thay vì ở trên, tôi chỉ đơn giản là làm suy yếu giới hạn truy cập. Tôi bỏ qua việc nghiên cứu mã sử dụng phương thức và tiến hành kiểm tra bằng cách gọi ra exPrivateMethod. Tuyệt quá? Không phải!
Tôi có đạt được một thử nghiệm cho việc sử dụng cụ thể API không riêng tư được đề cập ở trên không? Không: trước đây không có bài kiểm tra nào nonPrivateMethod(true)và hiện tại không có bài kiểm tra nào như vậy.
Các độc giả bên ngoài có cơ hội hiểu rõ hơn về việc sử dụng lớp học không? Không. "- Này, mục đích của phương pháp được thử nghiệm ở đây là gì? - Quên đi, nó hoàn toàn được sử dụng nội bộ. - Rất tiếc."
Có chịu được tái cấu trúc không? Không có cách nào: bất cứ điều gì tôi thay đổi exPrivateMethod, có thể sẽ phá vỡ bài kiểm tra. Đổi tên, hợp nhất vào một số phương thức khác, thay đổi đối số và kiểm tra sẽ chỉ dừng biên dịch. Đau đầu? Bạn đặt cược!
Tóm tắt , gắn bó với phương pháp riêng tư mang đến cho tôi một sự cải tiến hữu ích, đáng tin cậy trong các bài kiểm tra đơn vị. Ngược lại, việc làm suy yếu các giới hạn truy cập "về khả năng kiểm tra" chỉ mang lại cho tôi một đoạn mã kiểm tra khó hiểu, khó hiểu, có nguy cơ bị phá vỡ vĩnh viễn bởi bất kỳ cấu trúc lại nhỏ nào; thẳng thắn những gì tôi nhận được trông đáng ngờ như nợ kỹ thuật .
</ rant>