Làm thế nào để quyết định xem một phương pháp sẽ là riêng tư, được bảo vệ, nội bộ hay công khai?

Question

Tôi đang thiết kế một lớp học trong đó một số phương pháp sẽ không gây ra bất kỳ tác hại nào nếu chúng được hiển thị công khai. Nhưng chúng cũng có thể là riêng tư, vì chúng sẽ chỉ được sử dụng từ cùng một lớp trong dự án của tôi.

Làm họ nào có những ưu điểm sau:

1. Đơn vị Testable mà không cần bộ truy xuất.
2. Tính linh hoạt.

Làm họ tin có những ưu điểm sau:

1. tài liệu công cộng đơn giản hóa.
2. Một số lỗi không xác định không được hiển thị.

Nguyên tắc chung trong trường hợp này là gì?

Answer 1

Ồ, xin vui lòng đọc Ch. 06 của mã hoàn thành 2 bởi Steve McConnell, nếu bạn có quyền truy cập vào nó. Điều đó sẽ trả lời câu hỏi của bạn một cách hoàn hảo.

Nói chung, Nếu Phương thức phù hợp với "Persona" tổng thể của lớp học, hãy đặt nó ở chế độ công khai. Kỹ thuật hơn, cố gắng không phá vỡ sự trừu tượng. Tôi đã đưa ra một ví dụ, nhưng tôi không biết bối cảnh công việc của bạn và vì vậy các ví dụ có thể không liên quan.

Nếu bạn không cần, bạn không cần phải đặt Phương thức công khai.

Để thử nghiệm, +1 cho máy đánh bóng John.

Nhưng tôi thực sự không thể giải thích cho bạn ở đây như Steve đã giải thích trong CC2.

Tôi hy vọng OK để đăng tham chiếu Sách trên luồng lưu trữ truy cập? (Vui lòng nhận xét.)

Answer 2

Trong trường hợp này, tôi thường đặt chúng ở chế độ riêng tư nhất có thể và sau đó tăng khả năng truy cập của chúng khi cần (ví dụ: mã từ các lớp khác sẽ được hưởng lợi từ việc có thể truy cập trực tiếp vào các phương thức đó). Thật dễ dàng để thêm các phương thức vào một API và khó loại bỏ chúng hơn nhiều (mà không vi phạm mã khác).

Answer 3

Luôn làm mọi thứ càng riêng tư càng tốt.

Để kiểm tra đơn vị, đôi khi tôi làm thành viên nội bộ, sau đó sử dụng thuộc tính InternalsVisibleTo trong AssemblyInfo.cs để cho phép truy cập hội đồng kiểm tra đơn vị cho các thành viên nội bộ.

Answer 4

Tôi là một người hâm mộ lớn của chỉ công khai những gì bạn rõ ràng muốn công khai. Tôi thích cái kén an toàn ấm áp mà lớp tôi đưa cho tôi.

Answer 5

Các thành viên công khai duy nhất thuộc loại phải là một phần của giao diện công khai của chính loại đó. Mục tiêu của bạn nên là giảm thiểu giao diện của loại thành số lượng thành viên ít nhất và không để lộ ít hoạt động tiềm ẩn.

Answer 6

Tôi KHÔNG BAO GIỜ sẽ công khai thông tin cá nhân của mình! Giai đoạn.

Answer 7

Chỉ hiển thị những gì cần thiết cho khách hàng và tình huống sử dụng dự định của bạn và không có gì khác.Tôi sẽ không xem xét thử nghiệm đơn vị như một khách hàng và thực hiện thay đổi để mã không dành cho tiêu dùng công cộng để bắt đầu có thể truy cập công cộng chỉ vì mục đích thử nghiệm đơn vị. Nếu bạn làm, bạn sẽ làm lộn xộn api của bạn, giảm khả năng sử dụng api của bạn, và làm cho những thay đổi trong tương lai khó hơn và không lý tưởng vì bây giờ có thể có mã khách hàng sử dụng những gì được cho là api riêng.

Tôi sẽ kiểm tra xem bạn có lựa chọn thay thế tốt hơn hay không. Ví dụ, bạn có thể tạo các trình truy cập riêng trong Visual Studio 2005 và 2008 để tạo api không công khai của một lớp công khai cho mục đích thử nghiệm. Điều này có thể làm lộn xộn mã kiểm tra đơn vị của bạn nhưng với tôi điều quan trọng nhất là thiết kế của bạn và api bạn đang phát hành cho khách hàng của bạn bao gồm cả bạn và nhóm của bạn. Trên một lưu ý khác, tôi cũng đề cập đến việc thử nghiệm đơn vị cung cấp cho bạn một cơ hội tuyệt vời để xem thiết kế của bạn tốt như thế nào và mức tiêu thụ api của bạn dễ dàng như thế nào từ góc nhìn của khách hàng. Được trang bị với sự thất vọng, vấn đề, vv trong quá trình phát triển thử nghiệm đơn vị, bạn thực hiện các thay đổi để nâng cao api của bạn và thiết kế đơn giản hơn, đẹp và có thể sử dụng được.

Answer 8

Nếu bạn thấy khó kiểm tra kỹ lưỡng một lớp, thì lớp học có thể đang làm quá nhiều. Việc chia lớp bằng cách sử dụng bố cục có thể làm cho các đơn vị cá nhân dễ kiểm tra hơn.

Đôi khi điều đó có ý nghĩa, những lúc khác thì không. Chỉ là một ý nghĩ.