Tại sao chúng ta không nên sử dụng bảo vệ tĩnh trong java

Tôi đã trả lời câu hỏi này Có cách nào để ghi đè các biến lớp trong Java không? Bình luận đầu tiên với 36 phiếu tán thành là:

Nếu bạn nhìn thấy một protected static, hãy chạy.

Bất cứ ai có thể giải thích tại sao một protected staticcau mày?

Đó là một vấn đề mang tính phong cách hơn là một vấn đề trực tiếp. Nó cho thấy rằng bạn đã không suy nghĩ đúng đắn về những gì đang diễn ra với lớp học.

Hãy nghĩ về những gì staticcó nghĩa là:

Biến này tồn tại ở cấp độ lớp, nó không tồn tại riêng biệt cho từng cá thể và nó không tồn tại độc lập trong các lớp mở rộng tôi .

Hãy nghĩ về những gì protectedcó nghĩa là:

Biến này có thể được nhìn thấy bởi lớp này, các lớp trong cùng một gói và các lớp mở rộng tôi .

Hai ý nghĩa không hoàn toàn loại trừ nhau nhưng nó khá gần nhau.

Trường hợp duy nhất tôi có thể thấy nơi bạn có thể sử dụng cả hai cùng nhau là nếu bạn có một lớp trừu tượng được thiết kế để mở rộng và lớp mở rộng sau đó có thể sửa đổi hành vi bằng cách sử dụng các hằng số được xác định trong bản gốc. Mặc dù vậy, kiểu sắp xếp đó rất có thể sẽ rất lộn xộn và chỉ ra điểm yếu trong thiết kế của các lớp.

Trong hầu hết các trường hợp, sẽ tốt hơn nếu để các hằng số là công khai vì điều đó chỉ làm cho mọi thứ sạch sẽ hơn và cho phép mọi người phân loại phụ linh hoạt hơn. Hoàn toàn khác với bất kỳ thứ gì khác trong nhiều trường hợp, thành phần được ưu tiên hơn là kế thừa, trong khi các lớp trừu tượng buộc kế thừa.

Để xem một ví dụ về cách điều này có thể phá vỡ mọi thứ và để minh họa ý của tôi khi biến không tồn tại độc lập, hãy thử mã ví dụ sau:

public class Program {
    public static void main (String[] args) throws java.lang.Exception {
        System.out.println(new Test2().getTest());
        Test.test = "changed";
        System.out.println(new Test2().getTest());
    }
}

abstract class Test {
    protected static String test = "test";
}

class Test2 extends Test {
    public String getTest() {
        return test;
    }
}

Bạn sẽ thấy kết quả:

test
changed

Hãy tự mình thử tại: https://ideone.com/KM8u8O

Lớp Test2có thể truy cập thành viên tĩnh testtừ đó Testmà không cần đặt tên đủ điều kiện - nhưng nó không kế thừa hoặc lấy bản sao của chính nó. Nó đang nhìn vào cùng một đối tượng trong bộ nhớ.

Nó bị cau có vì nó mâu thuẫn.

Tạo một biến có protectednghĩa là nó sẽ được sử dụng trong gói hoặc nó sẽ được kế thừa trong một lớp con .

Việc đặt biến staticlàm cho nó trở thành một thành viên của lớp, loại bỏ ý định kế thừa nó . Điều này chỉ có ý định sử dụng trong một gói và chúng tôi cópackage-private cho điều đó (không có bổ sung).

Tình hình duy nhất tôi có thể tìm thấy hữu ích này là nếu bạn đã khai báo một lớp nên được sử dụng để khởi động các ứng dụng (như JavaFX của Application#launch, và chỉ muốn để có thể khởi động từ một lớp con. Nếu làm như vậy, đảm bảo phương pháp này cũng là finalđể không cho phép trốn . Nhưng đây không phải là "chuẩn mực" và có lẽ đã được triển khai để ngăn việc tăng thêm độ phức tạp bằng cách thêm một cách mới để khởi chạy ứng dụng.

Để xem các cấp độ truy cập của từng công cụ sửa đổi, hãy xem phần này: Hướng dẫn Java - Kiểm soát quyền truy cập vào các thành viên của một lớp

Tôi không thấy lý do cụ thể tại sao điều này phải được cau mày. Có thể luôn có các lựa chọn thay thế để đạt được cùng một hành vi và nó sẽ phụ thuộc vào bảo vệ thực tế liệu những lựa chọn thay thế này có "tốt hơn" so với một phương pháp tĩnh được bảo vệ hay không. Nhưng một ví dụ trong đó ít nhất một phương thức static được bảo vệ sẽ hợp lý có thể là:

(Đã chỉnh sửa để chia thành các gói riêng biệt, để sử dụng protectedrõ ràng hơn)

package a;
import java.util.List;

public abstract class BaseClass
{
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeDefaultB(list);
    }

    protected static Integer computeDefaultA(List<Integer> list)
    {
        return 12;
    }
    protected static Integer computeDefaultB(List<Integer> list)
    {
        return 34;
    }
}

Xuất phát từ đó:

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassA extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeDefaultA(list)+computeOwnB(list);
    }

    private static Integer computeOwnB(List<Integer> list)
    {
        return 56;
    }
}

Một lớp dẫn xuất khác:

package a.b;

import java.util.List;

import a.BaseClass;

abstract class ExtendingClassB extends BaseClass
{
    @Override
    public Integer compute(List<Integer> list)
    {
        return computeOwnA(list)+computeDefaultB(list);
    }

    private static Integer computeOwnA(List<Integer> list)
    {
        return 78;
    }
}

Công cụ protected staticsửa đổi chắc chắn có thể được giải thích ở đây:

• Các phương thức có thể như vậy static, bởi vì chúng không phụ thuộc vào các biến cá thể. Chúng không nhằm mục đích sử dụng trực tiếp như một phương thức đa hình, mà là các phương thức "tiện ích" cung cấp các triển khai mặc định là một phần của một phép tính phức tạp hơn và đóng vai trò là "khối xây dựng" của việc triển khai thực tế.
• Các phương pháp không nên như vậy public, bởi vì chúng là một chi tiết triển khai. Và chúng không thể được privatevì chúng nên được gọi bởi các lớp mở rộng. Chúng cũng không thể có khả năng hiển thị "mặc định", vì sau đó chúng sẽ không thể truy cập được đối với các lớp mở rộng trong các gói khác.

(CHỈNH SỬA: Người ta có thể cho rằng nhận xét ban đầu chỉ tham chiếu đến các trường chứ không phải các phương thức - tuy nhiên, sau đó, nó quá chung chung)

Các thành viên tĩnh không được kế thừa và các thành viên được bảo vệ chỉ hiển thị với các lớp con (và tất nhiên là cả lớp chứa), do đó, a protected staticcó cùng khả năng hiển thị static, gợi ý cho người lập trình hiểu lầm.

Trên thực tế, không có gì sai về cơ bản protected static. Nếu bạn thực sự muốn một biến hoặc phương thức tĩnh hiển thị cho gói và tất cả các lớp con của lớp khai báo thì hãy tiếp tục và tạo nó protected static.

Một số người thường tránh sử dụng protectedvì nhiều lý do khác nhau và một số người nghĩ rằng các staticbiến không cuối cùng nên được tránh bằng mọi cách (cá nhân tôi thông cảm với biến sau ở một mức độ nào đó), vì vậy tôi đoán sự kết hợp của protectedvà staticphải có vẻ xấu ^ 2 với những biến thuộc cả hai nhóm.

Protected được sử dụng để nó có thể được sử dụng trong các lớp con. Không có logic nào trong việc xác định một static được bảo vệ khi sử dụng trong ngữ cảnh của các lớp cụ thể vì bạn có thể truy cập vào cùng một biến là một cách tĩnh. Tuy nhiên, trình biên dịch sẽ đưa ra cảnh báo để truy cập vào biến static siêu lớp theo cách tĩnh.

Vâng, như hầu hết mọi người đã trả lời:

• protectedcó nghĩa là - ' gói-riêng tư + khả năng hiển thị đối với các lớp con - thuộc tính / hành vi được HẠNH PHÚC '
• staticcó nghĩa là - ' trường hợp ngược lại - nó là thuộc tính / hành vi CLASS, tức là nó KHÔNG ĐƯỢC HẠNH PHÚC '

Do đó chúng hơi mâu thuẫn và không tương thích.

Tuy nhiên, gần đây tôi đã đưa ra một trường hợp sử dụng trong đó có thể hợp lý khi sử dụng hai điều này cùng nhau. Hãy tưởng tượng rằng bạn muốn tạo một abstractlớp là lớp cha cho các kiểu bất biến và nó có một loạt các thuộc tính chung cho các kiểu con. Để triển khai tính bất biến đúng cách và duy trì tính dễ đọc, người ta có thể quyết định sử dụng mẫu Builder .

package X;
public abstract class AbstractType {
    protected Object field1;
    protected Object field2;
    ...
    protected Object fieldN;

    protected static abstract class BaseBuilder<T extends BaseBuilder<T>> {
        private Object field1; // = some default value here
        private Object field2; // = some default value here
        ...
        private Object fieldN; // = some default value here

        public T field1(Object value) { this.field1 = value; return self();}
        public T field2(Object value) { this.field2 = value; return self();}
        ...
        public T fieldN(Object value) { this.fieldN = value; return self();}
        protected abstract T self(); // should always return this;
        public abstract AbstractType build();
    }

    private AbstractType(BaseBuilder<?> b) {
        this.field1 = b.field1;
        this.field2 = b.field2;
        ...
        this.fieldN = b.fieldN;
    }
}

Và tại sao protected static? Bởi vì tôi muốn một kiểu con không trừu tượng trong AbstactTypeđó triển khai Bộ dựng không trừu tượng của riêng nó và nằm bên ngoài package Xđể có thể truy cập và sử dụng lại BaseBuilder.

package Y;
public MyType1 extends AbstractType {
    private Object filedN1;

    public static class Builder extends AbstractType.BaseBuilder<Builder> {
        private Object fieldN1; // = some default value here

        public Builder fieldN1(Object value) { this.fieldN1 = value; return self();}
        @Override protected Builder self() { return this; }
        @Override public MyType build() { return new MyType(this); }
    }

    private MyType(Builder b) {
        super(b);
        this.fieldN1 = b.fieldN1;
    }
}

Tất nhiên chúng ta có thể BaseBuildercông khai nhưng sau đó chúng ta lại đi đến một nhận định trái ngược khác:

• Chúng ta có một lớp không thể tức thời (trừu tượng)
• Chúng tôi cung cấp một trình tạo công khai cho nó

Vì vậy, trong cả hai trường hợp với protected staticvà publicxây dựngabstract class chúng tôi kết hợp các câu lệnh trái ngược nhau. Đó là một vấn đề của sở thích cá nhân.

Tuy nhiên, tôi vẫn thích publicxây dựng mộtabstract class vì đối protected staticvới tôi cảm thấy không tự nhiên hơn trong một thế giới OOD và OOP!

Không có gì sai khi có protected static. Một điều mà nhiều người đang bỏ qua là bạn có thể muốn viết các trường hợp thử nghiệm cho các phương thức tĩnh mà bạn không muốn để lộ trong các trường hợp bình thường. Tôi nhận thấy điều này đặc biệt hữu ích để viết các bài kiểm tra cho phương thức tĩnh trong các lớp tiện ích.