Khi nào tôi nên mở rộng một lớp Java Swing?

Sự hiểu biết hiện tại của tôi về việc thực hiện Kế thừa là người ta chỉ nên mở rộng một lớp nếu có mối quan hệ IS-A . Nếu lớp cha có thể có thêm các kiểu con cụ thể hơn với chức năng khác nhau nhưng sẽ chia sẻ các phần tử phổ biến được trừu tượng hóa trong lớp cha.

Tôi đang nghi ngờ sự hiểu biết đó vì những gì giáo sư Java của tôi khuyên chúng ta nên làm. Ông đã khuyến nghị rằng đối với một JSwingứng dụng chúng tôi đang xây dựng trong lớp

Người ta phải mở rộng tất cả JSwingcác lớp học ( JFrame, JButton, JTextBox, vv) vào các lớp tùy chỉnh riêng biệt và chỉ định GUI tùy biến có liên quan đến họ (như kích thước thành phần, thành phần nhãn, vv)

Cho đến nay vẫn tốt, nhưng ông tiếp tục khuyên rằng mỗi JButton nên có lớp mở rộng tùy chỉnh riêng của mình mặc dù yếu tố phân biệt duy nhất là nhãn của họ.

Ví dụ: Nếu GUI có hai nút Okay và Hủy . Ông khuyến nghị họ nên được gia hạn như sau:

class OkayButton extends JButton{
    MainUI mui;
    public OkayButton(MainUI mui) {
        setSize(80,60);
        setText("Okay");
        this.mui = mui;
        mui.add(this);        
    }
}

class CancelButton extends JButton{
    MainUI mui;
    public CancelButton(MainUI mui) {
        setSize(80,60);
        setText("Cancel");
        this.mui = mui;
        mui.add(this);        
    }
}

Như bạn có thể thấy sự khác biệt duy nhất là trong setTextchức năng.

Vậy đây có phải là tiêu chuẩn thực hành?

Btw, khóa học mà điều này đã được thảo luận được gọi là Thực tiễn lập trình tốt nhất trong Java

[Trả lời từ Giáo sư]

Vì vậy, tôi đã thảo luận vấn đề với giáo sư và nêu ra tất cả các điểm được đề cập trong các câu trả lời.

Lý do của ông là phân lớp cung cấp mã có thể tái sử dụng trong khi tuân theo các tiêu chuẩn thiết kế GUI. Chẳng hạn, nếu nhà phát triển đã sử dụng các nút tùy chỉnh Okayvà các Cancelnút trong một Cửa sổ, việc đặt các nút tương tự trong các Windows khác cũng sẽ dễ dàng hơn.

Tôi có lý do tôi cho rằng, nhưng vẫn chỉ là khai thác tính kế thừa và làm cho mã dễ vỡ.

Sau đó, bất kỳ nhà phát triển vô tình có thể gọi setTextvào một Okaynút và thay đổi nó. Lớp con chỉ trở nên phiền toái trong trường hợp đó.

Điều này vi phạm Nguyên tắc thay thế Liskov vì OkayButtonkhông thể thay thế ở bất kỳ nơi nào a Buttondự kiến. Ví dụ: bạn có thể thay đổi nhãn của bất kỳ nút nào bạn muốn. Nhưng làm điều đó với một OkayButtonvi phạm bất biến nội bộ của nó.

Đây là một lạm dụng cổ điển của thừa kế để tái sử dụng mã. Sử dụng một phương pháp trợ giúp thay thế.

Một lý do khác để không làm điều này là đây chỉ là một cách dễ dàng để đạt được điều tương tự như mã tuyến tính.

Nó hoàn toàn khủng khiếp theo mọi cách có thể. Nhiều nhất , sử dụng chức năng của nhà máy để tạo JButtons. Bạn chỉ nên thừa kế từ họ nếu bạn có một số nhu cầu mở rộng nghiêm trọng.

Đây là một cách viết mã không chuẩn. Thông thường, bạn chỉ hiếm khi tạo các lớp con của các thành phần UI UI, phổ biến nhất là JFrame (để thiết lập các cửa sổ con và trình xử lý sự kiện), nhưng ngay cả việc phân lớp đó là không cần thiết và được nhiều người nản lòng. Việc cung cấp tùy chỉnh văn bản cho các nút và tương tự thường được thực hiện bằng cách mở rộng lớp AbstractAction (hoặc giao diện Hành động mà nó cung cấp). Điều này có thể cung cấp văn bản, biểu tượng và tùy chỉnh trực quan cần thiết khác và liên kết chúng với mã thực tế mà chúng đại diện. Đây là một cách viết mã UI tốt hơn nhiều so với các ví dụ bạn hiển thị.

(nhân tiện, học giả google chưa bao giờ nghe về bài báo mà bạn trích dẫn - bạn có tài liệu tham khảo chính xác hơn không?)

IMHO, Thực tiễn lập trình tốt nhất trong Java được định nghĩa bởi cuốn sách "Java hiệu quả" của Joshua Bloch. Thật tuyệt khi giáo viên của bạn đang đưa cho bạn các bài tập OOP và điều quan trọng là học cách đọc và viết các kiểu lập trình của người khác. Nhưng bên ngoài cuốn sách của Josh Bloch, các ý kiến ​​khác nhau khá nhiều về các thực tiễn tốt nhất.

Nếu bạn sẽ mở rộng lớp này, bạn cũng có thể tận dụng sự kế thừa. Tạo một lớp MyButton để quản lý mã chung và lớp con cho các phần biến:

class MyButton extends JButton{
    protected final MainUI mui;
    public MyButton(MainUI mui, String text) {
        setSize(80,60);
        setText(text);
        this.mui = mui;
        mui.add(this);        
    }
}

class OkayButton extends MyButton{
    public OkayButton(MainUI mui) {
        super(mui, "Okay");
    }
}

class CancelButton extends MyButton{
    public CancelButton(MainUI mui) {
        super(mui, "Cancel");
    }
}

Khi nào thì đây là một ý tưởng tốt? Khi bạn sử dụng các loại bạn đã tạo! Chẳng hạn, nếu bạn có chức năng tạo cửa sổ bật lên và chữ ký là:

public void showPopUp(String text, JButton ok, JButton cancel)

Những loại bạn vừa tạo không làm gì tốt cả. Nhưng:

public void showPopUp(String text, OkButton ok, CancelButton cancel)

Bây giờ bạn đã tạo ra một cái gì đó hữu ích.

1. Trình biên dịch xác minh rằng showPopUp có một OkButton và CancButton. Ai đó đọc mã biết chức năng này được sử dụng như thế nào vì loại tài liệu này sẽ gây ra lỗi thời gian biên dịch nếu nó lỗi thời. Đây là một lợi ích CHÍNH. Các nghiên cứu thực nghiệm 1 hoặc 2 về lợi ích của an toàn loại cho thấy hiểu biết về mã người là lợi ích duy nhất có thể định lượng.

2. Điều này cũng ngăn ngừa lỗi khi bạn đảo ngược thứ tự các nút bạn chuyển đến chức năng. Những lỗi này rất khó phát hiện, nhưng chúng cũng khá hiếm, vì vậy đây là một lợi ích nhỏ. Điều này đã được sử dụng để bán loại an toàn, nhưng chưa được chứng minh bằng thực nghiệm là đặc biệt hữu ích.

3. Dạng đầu tiên của chức năng linh hoạt hơn vì nó sẽ hiển thị bất kỳ hai nút nào. Đôi khi điều đó tốt hơn là hạn chế loại nút sẽ sử dụng. Chỉ cần nhớ rằng bạn phải kiểm tra chức năng của bất kỳ nút nào trong nhiều trường hợp - nếu nó chỉ hoạt động khi bạn vượt qua chính xác loại nút bạn không làm bất kỳ ai ủng hộ bằng cách giả vờ nó sẽ lấy bất kỳ loại nút nào.

Vấn đề với lập trình hướng đối tượng là nó đặt giỏ hàng trước ngựa. Trước tiên, bạn cần viết hàm để biết chữ ký là gì để biết liệu có đáng để tạo kiểu cho nó không. Nhưng trong Java, bạn cần tạo các kiểu của mình trước để có thể viết chữ ký hàm.

Vì lý do này, bạn có thể muốn viết một số mã Clojure để xem mức độ tuyệt vời của việc viết các chức năng của bạn trước tiên. Bạn có thể mã hóa nhanh chóng, suy nghĩ về độ phức tạp tiệm cận càng nhiều càng tốt và giả định về tính bất biến của Clojure ngăn chặn các lỗi nhiều như các kiểu trong Java.

Tôi vẫn là một fan hâm mộ của các loại tĩnh cho các dự án lớn và hiện sử dụng một số tiện ích chức năng cho phép tôi viết các hàm trước và đặt tên cho các loại của mình sau trong Java . Chỉ là một ý nghĩ.

PS Tôi đã thực hiện muicon trỏ cuối cùng - nó không cần phải thay đổi.

Tôi sẵn sàng đặt cược rằng giáo viên của bạn không thực sự tin rằng bạn nên luôn mở rộng thành phần Xoay để sử dụng nó. Tôi cá là họ chỉ sử dụng điều này như một ví dụ để buộc bạn thực hành mở rộng các lớp học. Tôi sẽ không lo lắng quá nhiều về các thực hành tốt nhất trong thế giới thực.

Điều đó đang được nói, trong thế giới thực, chúng tôi ủng hộ sáng tác hơn thừa kế .

Quy tắc "người ta chỉ nên mở rộng một lớp nếu có mối quan hệ IS-A" không đầy đủ. Nó sẽ kết thúc bằng "... và chúng ta cần thay đổi hành vi mặc định của lớp" bằng các chữ in đậm lớn.

Ví dụ của bạn không phù hợp với tiêu chí đó. Bạn không cần phải extendcác JButtonlớp chỉ để thiết lập văn bản của nó. Bạn không cần phải extendcác JFramelớp chỉ để thêm các thành phần với nó. Bạn có thể làm những điều này tốt bằng cách sử dụng các triển khai mặc định của chúng, vì vậy việc thêm thừa kế chỉ là thêm các biến chứng không cần thiết.

Nếu tôi thấy một lớp mà extendsmột lớp khác, tôi sẽ tự hỏi lớp đó đang thay đổi . Nếu bạn không thay đổi bất cứ điều gì, đừng bắt tôi phải xem qua lớp học.

Quay lại câu hỏi của bạn: khi nào bạn nên mở rộng một lớp Java? Khi bạn có một lý do thực sự, thực sự, thực sự tốt để mở rộng một lớp học.

Đây là một ví dụ cụ thể: một cách để thực hiện vẽ tùy chỉnh (cho trò chơi hoặc hoạt hình hoặc chỉ cho một thành phần tùy chỉnh) là bằng cách mở rộng JPanellớp. (Xem thêm thông tin về điều đó ở đây .) Bạn mở rộng JPanellớp vì bạn cần phải ghi đè lên các paintComponent()chức năng. Bạn đang thực sự thay đổi hành vi của lớp bằng cách làm điều này. Bạn không thể thực hiện vẽ tùy chỉnh với việc JPanelthực hiện mặc định .

Nhưng như tôi đã nói, giáo viên của bạn có lẽ chỉ sử dụng những ví dụ này như một cái cớ để buộc bạn thực hành mở rộng các lớp học.