tìm kiếm một trường hợp sử dụng cụ thể trong đó cả lớp con và lớp trong cùng một gói cần truy cập vào trường hoặc phương thức được bảo vệ ...
Đối với tôi, trường hợp sử dụng như vậy khá chung chung và cụ thể bắt nguồn từ sở thích của tôi để:
- Bắt đầu với công cụ sửa đổi truy cập chặt chẽ nhất có thể, chỉ dùng đến một (các) yếu hơn sau khi thấy cần thiết.
- Có các bài kiểm tra đơn vị nằm trong cùng gói với mã được kiểm tra.
Từ trên, tôi có thể bắt đầu thiết kế cho các đối tượng của mình bằng các công cụ sửa đổi truy cập mặc định (tôi sẽ bắt đầu với privatenhưng điều đó sẽ làm phức tạp việc kiểm tra đơn vị):
public class Example {
public static void main(String [] args) {
new UnitTest().testDoSomething(new Unit1(), new Unit2());
}
static class Unit1 {
void doSomething() {} // default access
}
static class Unit2 {
void doSomething() {} // default access
}
static class UnitTest {
void testDoSomething(Unit1 unit1, Unit2 unit2) {
unit1.doSomething();
unit2.doSomething();
}
}
}
Lưu ý bên trong đoạn mã trên, Unit1, Unit2và UnitTestđược lồng vào trong Examplevì đơn giản của bài trình bày, nhưng trong một dự án thực tế, tôi có khả năng sẽ có những lớp trong các file riêng biệt (và UnitTestthậm chí trong một thư mục riêng biệt ).
Sau đó, khi có nhu cầu phát sinh, tôi sẽ làm suy yếu quyền kiểm soát truy cập từ mặc định thành protected:
public class ExampleEvolved {
public static void main(String [] args) {
new UnitTest().testDoSomething(new Unit1(), new Unit2());
}
static class Unit1 {
protected void doSomething() {} // made protected
}
static class Unit2 {
protected void doSomething() {} // made protected
}
static class UnitTest {
// ---> no changes needed although UnitTest doesn't subclass
// ...and, hey, if I'd have to subclass... which one of Unit1, Unit2?
void testDoSomething(Unit1 unit1, Unit2 unit2) {
unit1.doSomething();
unit2.doSomething();
}
}
}
Bạn thấy đấy, tôi có thể giữ mã kiểm tra đơn vị ExampleEvolvedkhông thay đổi do các phương thức được bảo vệ có thể truy cập được từ cùng một gói, mặc dù đối tượng truy cập không phải là một lớp con .
Ít thay đổi cần thiết => sửa đổi an toàn hơn; sau tất cả, tôi đã thay đổi chỉ các công cụ sửa đổi truy cập và tôi đã không sửa đổi phương thức nào Unit1.doSomething()và Unit2.doSomething()thực hiện, do đó, việc mong đợi mã kiểm tra đơn vị tiếp tục chạy mà không cần sửa đổi là điều tự nhiên.
protectedlà lớp con? Thành thật mà nói, trong một thời gian dài, tôi đã có ấn tượng rằng đó là hành vi