Tôi có nên tránh sử dụng các phương thức Kích thước tập hợp (Ưu tiên | Tối đa | Tối thiểu) trong Java Swing không?

Một vài lần tôi đã bị chỉ trích vì đã đề nghị sử dụng các phương pháp sau:

1. setPreferredSize
2. setMinimumSize
3. setMaximumSize

trên Swingcác thành phần. Tôi không thấy bất kỳ sự thay thế nào cho việc sử dụng chúng khi tôi muốn xác định tỷ lệ giữa các thành phần được hiển thị. Tôi đã được nói điều này:

Với bố cục, câu trả lời luôn giống nhau: sử dụng Trình quản lý bố cục phù hợp

Tôi đã tìm kiếm trên web một chút, nhưng tôi không tìm thấy bất kỳ phân tích toàn diện nào về chủ đề này. Vì vậy, tôi có các câu hỏi sau đây:

1. Tôi có nên tránh hoàn toàn việc sử dụng các phương pháp đó?
2. Các phương pháp đã được xác định cho một lý do. Vậy khi nào tôi nên sử dụng chúng? Trong bối cảnh nào? Vì mục đích gì?
3. Chính xác những hậu quả tiêu cực của việc sử dụng các phương pháp đó là gì? (Tôi chỉ có thể nghĩ thêm tính di động giữa các hệ thống có độ phân giải màn hình khác nhau).
4. Tôi không nghĩ rằng bất kỳ LayoutManager nào có thể đáp ứng chính xác tất cả các nhu cầu bố trí mong muốn. Tôi có thực sự cần phải triển khai một Trình quản lý bố cục mới cho mỗi biến thể nhỏ trên bố cục của mình không?
5. Nếu câu trả lời cho 4 là "có", điều này sẽ không dẫn đến sự phổ biến của các lớp LayoutManager sẽ trở nên khó duy trì?
6. Trong tình huống tôi cần xác định tỷ lệ giữa các con của Thành phần (ví dụ: child1 nên sử dụng 10% dung lượng, child2 40%, child3 50%), có thể đạt được điều đó mà không cần thực hiện Trình quản lý bố cục tùy chỉnh không?

1. Tôi có nên tránh hoàn toàn việc sử dụng các phương pháp đó?

   Có cho mã ứng dụng.

2. Các phương pháp đã được xác định cho một lý do. Vậy khi nào tôi nên sử dụng chúng? Trong bối cảnh nào? Vì mục đích gì?

   Tôi không biết, cá nhân tôi nghĩ đó là một tai nạn thiết kế API. Hơi bị ép buộc bởi các thành phần hỗn hợp có ý tưởng đặc biệt về kích thước trẻ em. "Hơi", vì lẽ ra họ nên thực hiện nhu cầu của mình với Trình quản lý bố cục tùy chỉnh.

3. Chính xác những hậu quả tiêu cực của việc sử dụng các phương pháp đó là gì? (Tôi chỉ có thể nghĩ thêm tính di động giữa các hệ thống có độ phân giải màn hình khác nhau.)

   Một số (không đầy đủ và không may là các liên kết bị hỏng do di chuyển SwingLabs sang java.net), ví dụ như các lý do kỹ thuật được đề cập trong Quy tắc (hehe) hoặc trong liên kết @bendicott được tìm thấy trong nhận xét của anh ấy / cô ấy cho câu trả lời của tôi . Về mặt xã hội, đặt ra hàng tấn công việc cho người bạn không may của bạn, người phải duy trì mã và phải theo dõi một bố cục bị hỏng.

4. Tôi không nghĩ rằng bất kỳ LayoutManager nào có thể đáp ứng chính xác tất cả các nhu cầu bố trí mong muốn. Tôi có thực sự cần phải triển khai một Trình quản lý bố cục mới cho mỗi biến thể nhỏ trên bố cục của mình không?

   Có, có Trình quản lý Bố cục đủ mạnh để đáp ứng xấp xỉ rất tốt cho "tất cả các nhu cầu bố trí". Ba công cụ lớn là Joodies FormLayout, MigLayout, DesignGridLayout. Vì vậy, trong thực tế, bạn hiếm khi viết Trình quản lý ngoại trừ các môi trường đơn giản có tính chuyên môn cao.

5. Nếu câu trả lời cho 4 là "có", điều này sẽ không dẫn đến sự phổ biến của các lớp LayoutManager sẽ trở nên khó duy trì?

   (Câu trả lời cho 4 là "không".)

6. Trong tình huống tôi cần xác định tỷ lệ giữa các con của Thành phần (ví dụ: con 1 nên sử dụng 10% dung lượng, con 2 40%, con 3 50%), có thể đạt được điều đó mà không cần thực hiện Trình quản lý bố cục tùy chỉnh không?

   Bất kỳ Big-Three nào cũng có thể, thậm chí không thể là GridBag (không bao giờ bận tâm đến việc thực sự thành thạo, quá nhiều rắc rối vì quá ít năng lượng).

Một vài phương pháp phỏng đoán:

• Không sử dụng set[Preferred|Maximum|Minimum]Size()khi bạn thực sự muốn ghi đè get[Preferred|Maximum|Minimum]Size(), như có thể được thực hiện trong việc tạo thành phần của riêng bạn, được hiển thị ở đây .

• Không sử dụng set[Preferred|Maximum|Minimum]Size()khi bạn có thể dựa vào ghi đè cẩn thận của một thành phần getPreferred|Maximum|Minimum]Size, như hiển thị ở đây và bên dưới.

• Sử dụng set[Preferred|Maximum|Minimum]Size()để lấy được hậu validate()hình học, như hiển thị bên dưới và ở đây .

• Nếu một thành phần không có kích thước ưa thích, ví dụ JDesktopPane, bạn có thể phải kích thước thùng chứa, nhưng bất kỳ lựa chọn nào như vậy là tùy ý. Một bình luận có thể giúp làm rõ ý định.

• Xem xét bố cục thay thế hoặc tùy chỉnh khi bạn thấy rằng bạn sẽ phải lặp qua nhiều thành phần để có được kích thước dẫn xuất, như đã đề cập trong các nhận xét này .

import java.awt.Component;
import java.awt.Dimension;
import java.awt.EventQueue;
import java.awt.GridLayout;
import java.awt.KeyboardFocusManager;
import java.beans.PropertyChangeEvent;
import java.beans.PropertyChangeListener;
import java.util.ArrayList;
import java.util.List;
import javax.swing.JComponent;
import javax.swing.JDesktopPane;
import javax.swing.JFrame;
import javax.swing.JInternalFrame;
import javax.swing.JLabel;
import javax.swing.JPanel;
import javax.swing.JScrollPane;
import javax.swing.JTextField;
import javax.swing.SwingUtilities;

/**
 * @see /programming/7229226
 * @see /programming/7228843
 */
public class DesignTest {

    private List<JTextField> list = new ArrayList<JTextField>();
    private JPanel panel = new JPanel();
    private JScrollPane sp = new JScrollPane(panel);

    public static void main(String args[]) {
        EventQueue.invokeLater(new Runnable() {

            @Override
            public void run() {
                DesignTest id = new DesignTest();
                id.create("My Project");
            }
        });
    }

    private void addField(String name) {
        JTextField jtf = new JTextField(16);
        panel.add(new JLabel(name, JLabel.LEFT));
        panel.add(jtf);
        list.add(jtf);
    }

    private void create(String strProjectName) {
        panel.setLayout(new GridLayout(0, 1));
        addField("First Name:");
        addField("Last Name:");
        addField("Address:");
        addField("City:");
        addField("Zip Code:");
        addField("Phone:");
        addField("Email Id:");
        KeyboardFocusManager.getCurrentKeyboardFocusManager()
            .addPropertyChangeListener("permanentFocusOwner",
            new FocusDrivenScroller(panel));
        // Show half the fields
        sp.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_ALWAYS);
        sp.validate();
        Dimension d = sp.getPreferredSize();
        d.setSize(d.width, d.height / 2);
        sp.setPreferredSize(d);

        JInternalFrame internaFrame = new JInternalFrame();
        internaFrame.add(sp);
        internaFrame.pack();
        internaFrame.setVisible(true);

        JDesktopPane desktopPane = new JDesktopPane();
        desktopPane.add(internaFrame);

        JFrame frmtest = new JFrame();
        frmtest.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
        frmtest.add(desktopPane);
        frmtest.pack();
        // User's preference should be read from java.util.prefs.Preferences
        frmtest.setSize(400, 300);
        frmtest.setLocationRelativeTo(null);
        frmtest.setVisible(true);
        list.get(0).requestFocusInWindow();
    }

    private static class FocusDrivenScroller implements PropertyChangeListener {

        private JComponent parent;

        public FocusDrivenScroller(JComponent parent) {
            this.parent = parent;
        }

        @Override
        public void propertyChange(PropertyChangeEvent evt) {
            Component focused = (Component) evt.getNewValue();
            if (focused != null
                && SwingUtilities.isDescendingFrom(focused, parent)) {
                parent.scrollRectToVisible(focused.getBounds());
            }
        }
    }
}

Tôi có nên tránh hoàn toàn việc sử dụng các phương pháp đó?

Không, không có bằng chứng chính thức nào cho thấy việc gọi hoặc ghi đè các phương thức này là không được phép. Trên thực tế, Oracle cho biết các phương thức này được sử dụng để đưa ra gợi ý về kích thước: http://docs.oracle.com/javase/tutorial/uiswing/layout/USE.html#sizealocate .

Chúng cũng có thể bị ghi đè (đó là cách thực hành tốt nhất cho Xoay) khi mở rộng thành phần Xoay (thay vì gọi phương thức trên thể hiện thành phần tùy chỉnh)

Quan trọng nhất cho dù bạn chỉ định kích thước thành phần của mình như thế nào, hãy chắc chắn rằng bộ chứa thành phần của bạn sử dụng trình quản lý bố cục tôn trọng kích thước được yêu cầu của thành phần.

Các phương pháp đã được xác định cho một lý do. Vậy khi nào tôi nên sử dụng chúng? Trong bối cảnh nào? Vì mục đích gì?

Khi bạn cần cung cấp gợi ý kích thước tùy chỉnh cho bộ chứa Trình quản lý bố cục để thành phần sẽ được bố trí tốt

Chính xác những hậu quả tiêu cực của việc sử dụng các phương pháp đó là gì? (Tôi chỉ có thể nghĩ để thêm tính di động giữa các hệ thống có độ phân giải màn hình khác nhau).

• Nhiều người quản lý bố cục không chú ý đến kích thước tối đa được yêu cầu của một thành phần. Tuy nhiên, BoxLayoutvà SpringLayoutlàm. Hơn nữa, GroupLayoutcung cấp khả năng đặt kích thước tối thiểu, ưu tiên hoặc tối đa một cách rõ ràng mà không cần chạm vào thành phần.

• Đảm bảo rằng bạn thực sự cần đặt kích thước chính xác của thành phần. Mỗi thành phần Swing có kích thước ưa thích khác nhau, tùy thuộc vào phông chữ mà nó sử dụng và giao diện. Như vậy có kích thước bộ có thể tạo đa dạng ngoại hình của giao diện người dùng trên hệ thống khác nhau

• đôi khi các vấn đề có thể gặp phải GridBagLayoutvà các trường văn bản, trong đó nếu kích thước của vùng chứa nhỏ hơn kích thước ưa thích, kích thước tối thiểu được sử dụng, điều này có thể khiến các trường văn bản co lại đáng kể.

• JFramekhông thực thi overriden getMinimumSize()chỉ kêu gọi setMinimumSize(..)các công trình của nó

Tôi không nghĩ rằng bất kỳ LayoutManager nào có thể đáp ứng chính xác tất cả các nhu cầu bố trí mong muốn. Tôi có thực sự cần phải triển khai một Trình quản lý bố cục mới cho mỗi biến thể nhỏ trên bố cục của mình không?

Nếu bằng cách thực hiện bạn có nghĩa là sử dụng thì có. Không ai LayoutMangercó thể xử lý tất cả mọi thứ, mỗi cái đều LayoutManagercó ưu và nhược điểm, do đó mỗi cái có thể được sử dụng cùng nhau để tạo ra bố cục cuối cùng.

Tài liệu tham khảo:

• http://docs.oracle.com/javase/tutorial/uiswing/layout/probols.html

Có rất nhiều câu trả lời hay ở đây nhưng tôi muốn nói thêm một chút về lý do tại sao bạn thường nên tránh những câu hỏi này (câu hỏi chỉ xuất hiện lại trong một chủ đề trùng lặp):

Với một vài ngoại lệ, nếu bạn đang sử dụng các phương pháp này, có lẽ bạn đang tinh chỉnh GUI của mình để trông đẹp hơn trên giao diện cụ thể (và với các cài đặt dành riêng cho hệ thống của bạn, ví dụ: phông chữ trên màn hình ưa thích của bạn, v.v.). Bản thân các phương pháp không phải là xấu, nhưng lý do điển hình cho việc sử dụng chúng là . Ngay khi bạn bắt đầu điều chỉnh các vị trí và kích thước pixel trong bố cục, bạn sẽ có nguy cơ bị vỡ GUI (hoặc tối thiểu, trông xấu), trên các nền tảng khác.

Để làm ví dụ cho điều này, hãy thử thay đổi giao diện mặc định của ứng dụng của bạn. Ngay cả với các tùy chọn có sẵn trên nền tảng của bạn, bạn có thể ngạc nhiên về kết quả có thể được hiển thị kém như thế nào.

Vì vậy, nhân danh việc giữ cho GUI của bạn hoạt động tốt và đẹp mắt trên tất cả các nền tảng (hãy nhớ rằng, một trong những lợi ích chính của Java là tính đa nền tảng của nó), bạn nên dựa vào các trình quản lý bố cục, v.v., để tự động điều chỉnh kích thước của các thành phần của bạn để nó hiển thị chính xác bên ngoài môi trường phát triển cụ thể của bạn.

Tất cả những gì đã nói, bạn chắc chắn có thể hình dung ra các tình huống trong đó các phương pháp này là hợp lý. Một lần nữa, chúng không phải là xấu, nhưng việc sử dụng chúng thường là một lá cờ đỏ lớn cho thấy các vấn đề GUI tiềm ẩn. Chỉ cần đảm bảo rằng bạn nhận thức được khả năng biến chứng cao nếu / khi bạn sử dụng chúng và luôn cố gắng suy nghĩ nếu có một giải pháp độc lập khác về ngoại hình cho các vấn đề của bạn - thường xuyên hơn là bạn sẽ không thấy rằng những điều này phương pháp không cần thiết.

Nhân tiện, nếu bạn thấy mình nản lòng với các trình quản lý bố cục tiêu chuẩn, có rất nhiều bên thứ ba nguồn mở, miễn phí tốt, ví dụ như Joodies 'FormLayout , hoặc MigLayout. Một số trình xây dựng GUI thậm chí còn có hỗ trợ tích hợp cho các trình quản lý bố cục của bên thứ ba - ví dụ, trình soạn thảo GUI WindowBuilder của Eclipse có các hỗ trợ cho FormLayoutvà MigLayout.

Nếu bạn đang gặp rắc rối với các bố cục trong Java Swing, thì tôi hoàn toàn có thể đề xuất các Joodies FormLayoutđược cung cấp miễn phí như một phần của thư viện phần mềm miễn phí Forms của Karsten Lentzsch tại đây .

Trình quản lý bố cục rất phổ biến này cực kỳ linh hoạt, cho phép phát triển các UI Java rất bóng bẩy.

Bạn sẽ tìm thấy tài liệu của Karsten ở đây , và một số tài liệu khá hay từ nhật thực ở đây .

Những phương pháp này được hầu hết mọi người hiểu kém. Bạn tuyệt đối không nên bỏ qua các phương pháp này. Tùy thuộc vào trình quản lý bố cục nếu họ tôn trọng các phương thức này. Trang này có một bảng cho biết người quản lý bố cục nào tôn vinh phương thức nào:

http://thebadprogrammer.com/swing-layout-manager-sizing/

Tôi đã viết mã Swing trong hơn 8 năm và các trình quản lý bố cục có trong JDK luôn phục vụ nhu cầu của tôi. Tôi chưa bao giờ cần một người quản lý bố trí bên thứ 3 để đạt được bố cục của mình.

Tôi sẽ nói rằng bạn không nên cố gắng đưa ra gợi ý cho trình quản lý bố cục với các phương thức này cho đến khi bạn chắc chắn rằng mình cần chúng. Thực hiện bố cục của bạn mà không đưa ra bất kỳ gợi ý kích thước nào (nghĩa là để trình quản lý bố cục thực hiện công việc của nó) và sau đó bạn có thể thực hiện các chỉnh sửa nhỏ nếu bạn cần.

Trong tình huống tôi cần xác định tỷ lệ giữa các con của Thành phần (con 1 nên sử dụng 10% dung lượng, con2 40%, con3 50%), có thể đạt được điều đó mà không cần thực hiện trình quản lý bố cục tùy chỉnh không?

Có lẽ GridBagLayoutsẽ đáp ứng nhu cầu của bạn. Bên cạnh đó, có rất nhiều trình quản lý bố cục trên web và tôi cá là có một trình quản lý phù hợp với yêu cầu của bạn.

Tôi đang thấy nó khác với câu trả lời được chấp nhận.

1) Tôi có nên tránh hoàn toàn việc sử dụng các phương pháp đó không?

Không bao giờ tránh! Chúng ở đó để thể hiện các ràng buộc kích thước của các thành phần của bạn với trình quản lý bố cục. Bạn có thể tránh sử dụng chúng nếu bạn không sử dụng bất kỳ trình quản lý bố cục nào và cố gắng tự mình quản lý bố cục trực quan.

Thật không may, Swing không đến với kích thước mặc định hợp lý. Tuy nhiên, thay vì đặt kích thước của một thành phần, OOP tốt hơn là hạ xuống thành phần của chính bạn với mặc định hợp lý. (Trong trường hợp đó, bạn gọi setXXX trong lớp con cháu của mình.) Ngoài ra, bạn có thể ghi đè các phương thức getXXX cho cùng một hiệu ứng.

2) Các phương pháp đã được xác định vì một lý do. Vậy khi nào tôi nên sử dụng chúng? Trong bối cảnh nào? Vì mục đích gì?

Luôn luôn. Khi bạn tạo một thành phần, hãy đặt kích thước tối thiểu / ưa thích / tối đa thực tế của nó theo việc sử dụng thành phần đó. Ví dụ: nếu bạn có JTextField để nhập các ký hiệu quốc gia như Vương quốc Anh, kích thước ưa thích của nó sẽ rộng bằng hai ký tự (với phông chữ hiện tại, v.v.) nhưng có lẽ sẽ vô nghĩa khi để nó lớn hơn nữa. Rốt cuộc, biểu tượng đất nước là hai ký tự. Ngược lại, nếu bạn có JTextField để nhập ví dụ như tên khách hàng, nó có thể có kích thước ưa thích như kích thước pixel cho 20 ký tự, nhưng có thể tăng lên lớn hơn nếu bố cục được thay đổi kích thước, vì vậy hãy đặt kích thước tối đa thành nhiều hơn. Đồng thời, việc có một JTextField rộng 0px là vô nghĩa, vì vậy hãy đặt kích thước tối thiểu thực tế (tôi sẽ nói kích thước pixel là 2 ký tự).

3) Chính xác những hậu quả tiêu cực của việc sử dụng các phương pháp đó là gì?

(Tôi chỉ có thể nghĩ thêm tính di động giữa các hệ thống có độ phân giải màn hình khác nhau).

Không có hậu quả tiêu cực. Đây là những gợi ý cho người quản lý bố trí.

4) Tôi không nghĩ rằng bất kỳ Trình quản lý bố cục nào có thể đáp ứng chính xác tất cả các nhu cầu bố trí mong muốn.

Tôi có thực sự cần phải triển khai một Trình quản lý bố cục mới cho mỗi biến thể nhỏ trên bố cục của mình không?

Không chắc chắn không. Cách tiếp cận thông thường là xếp tầng các cách bố trí cơ bản khác nhau như bố trí ngang và dọc.

Ví dụ: bố cục bên dưới:

<pre>
+--------------+--------+
| ###JTABLE### | [Add]  | 
| ...data...   |[Remove]|
| ...data...   |        |
| ...data...   |        |
+--------------+--------+
</pre>

đang có hai phần. Phần bên trái và bên phải là một bố cục ngang. Phần bên phải là một JPanel được thêm vào bố cục theo chiều ngang và JPanel này có bố cục dọc để đặt các nút theo chiều dọc.

Tất nhiên, điều này có thể phát triển khó khăn với một bố cục thực tế. Do đó, các trình quản lý bố cục dựa trên lưới như MigLayout sẽ tốt hơn nhiều nếu bạn sắp phát triển bất cứ điều gì nghiêm trọng.

5) Nếu câu trả lời cho 4 là "có", điều này sẽ không dẫn đến sự phổ biến của các lớp LayoutManager sẽ trở nên khó duy trì?

Không, bạn chắc chắn sẽ không phát triển trình quản lý bố cục, trừ khi bạn cần một cái gì đó rất đặc biệt.

6) Trong tình huống tôi cần xác định tỷ lệ ...

giữa các con của Thành phần (ví dụ: child1 nên sử dụng 10% dung lượng, child2 40%, child3 50%), có thể đạt được điều đó mà không cần thực hiện Trình quản lý tùy chỉnh không?

Về cơ bản, một khi các kích thước ưa thích được đặt đúng, bạn có thể không muốn làm bất cứ điều gì theo tỷ lệ phần trăm. Đơn giản, bởi vì tỷ lệ phần trăm là vô nghĩa (ví dụ như vô nghĩa khi có JTextField 10% kích thước cửa sổ - vì người ta có thể thu nhỏ cửa sổ để JTextField trở nên rộng 0px hoặc có thể mở rộng cửa sổ để JTextField nằm trên hai màn hình trên một thiết lập đa màn hình).

Nhưng, đôi khi bạn có thể sử dụng tỷ lệ phần trăm để kiểm soát kích thước của các khối xây dựng lớn hơn của gui của bạn (ví dụ: bảng điều khiển).

Bạn có thể sử dụng JSplitPane nơi bạn có thể đặt trước tỷ lệ của hai bên. Hoặc, bạn có thể sử dụng MigLayout cho phép bạn đặt các ràng buộc đó theo tỷ lệ phần trăm, pixel và các đơn vị khác.

Tôi có nên tránh hoàn toàn việc sử dụng các phương pháp đó? Tôi sẽ không nói "tránh" chúng. Tôi muốn nói rằng nếu bạn nghĩ rằng bạn cần họ, có lẽ bạn đã làm sai điều gì đó. Kích thước thành phần được xác định trong bối cảnh. Ví dụ: Kích thước thành phần Văn bản được xác định theo số lượng hàng và cột bạn chỉ định, kết hợp với phông chữ bạn có thể đã chọn. Nút và kích thước nhãn của bạn sẽ là kích thước của đồ họa, nếu bạn đặt một hoặc không gian cần thiết để hiển thị văn bản bạn đặt. Mỗi thành phần có kích thước tự nhiên và trình quản lý bố cục sẽ sử dụng các kích thước đó để bố trí mọi thứ mà không cần bạn chỉ định kích thước. Ngoại lệ chính là JScrollPane, có kích thước độc lập với bất cứ thứ gì nó chứa. Đối với những người đó, đôi khi tôi sẽ gọi setSize()và để kích thước đó xác định kích thước cửa sổ ban đầu, bằng cách gọiJFrame.pack(). Thông thường, tôi sẽ để kích thước cửa sổ xác định kích thước JScrollPane. Người dùng sẽ xác định kích thước của cửa sổ. Nhiều trình quản lý bố cục bỏ qua các kích thước bạn đặt, vì vậy chúng thường không hoạt động tốt.

Các phương pháp đã được xác định cho một lý do. Vậy khi nào tôi nên sử dụng chúng? Trong bối cảnh nào? Vì mục đích gì? Tôi tin rằng họ đã được thêm vào để cung cấp gợi ý cho các nhà quản lý bố trí. Chúng có thể đã được viết vì lý do lịch sử, bởi vì các trình quản lý bố cục là mới và mọi người không hoàn toàn tin tưởng chúng. Tôi biết một vài nhà phát triển đã tránh các trình quản lý bố cục và đặt mọi thứ theo cách thủ công, chỉ vì họ không muốn bận tâm đến việc học một mô hình mới. Đó là một ý tưởng khủng khiếp.

Chính xác những hậu quả tiêu cực của việc sử dụng các phương pháp đó là gì? (Tôi chỉ có thể nghĩ thêm tính di động giữa các hệ thống có độ phân giải màn hình khác nhau). Chúng không hiệu quả, và chúng tạo ra bố cục xấu, với các vật thể bị ép hoặc kéo dài đến kích thước không tự nhiên. Và các bố trí sẽ giòn. Thay đổi kích thước cửa sổ đôi khi sẽ phá vỡ bố cục và đặt mọi thứ ở sai vị trí.

Tôi không nghĩ rằng bất kỳ LayoutManager nào có thể đáp ứng chính xác tất cả các nhu cầu bố trí mong muốn. Tôi có thực sự cần phải triển khai một Trình quản lý bố cục mới cho mỗi biến thể nhỏ trên bố cục của mình không? Bạn không nên "triển khai" một Trình quản lý bố cục mới. Bạn nên khởi tạo những cái hiện có. Tôi thường sử dụng một số trình quản lý bố cục trong một cửa sổ duy nhất. Mỗi JPanel sẽ có trình quản lý bố cục riêng. Một số người chùn bước tại các bố cục lồng nhau, vì họ khó duy trì. Khi tôi sử dụng chúng, tôi cung cấp cho mỗi người một phương pháp sáng tạo riêng để dễ dàng xem những gì mỗi người làm. Nhưng tôi không bao giờ "thực hiện" một trình quản lý bố cục. Tôi chỉ cần khởi tạo chúng.

Nếu câu trả lời cho 4 là "có", điều này sẽ không dẫn đến sự phổ biến của các lớp LayoutManager sẽ trở nên khó duy trì? Nếu bạn đang triển khai các lớp trình quản lý bố cục mới cho các thay đổi nhỏ trong bố cục, thì bạn đang sử dụng chúng sai. Nếu bạn chỉ thực hiện các trình quản lý bố cục mới, có lẽ bạn đã làm sai điều gì đó. Lần duy nhất tôi đã mở rộng một lớp LayoutManager, đó là thêm một thanh trượt thu phóng vào một JScrollPane.

Trong tình huống tôi cần xác định tỷ lệ giữa các con của Thành phần (ví dụ: child1 nên sử dụng 10% dung lượng, child2 40%, child3 50%), có thể đạt được điều đó mà không cần thực hiện Trình quản lý bố cục tùy chỉnh không? JSplitPane có cách chỉ định tỷ lệ phần trăm mà mỗi thành phần sẽ nhận được. Bộ chia có thể di chuyển theo mặc định, nhưng bạn có thể tắt nó nếu bạn muốn. Tôi không sử dụng tính năng đó nhiều. Tôi thường có một số thành phần chiếm kích thước đã đặt và phần còn lại của không gian được chiếm bởi một ngăn cuộn. Kích thước khung cuộn sẽ điều chỉnh với kích thước cửa sổ. Nếu bạn có hai tấm cuộn cạnh nhau, bạn có thể đặt chúng vào một JSplitPane và chỉ định tỷ lệ phần trăm không gian mới được cung cấp cho mỗi cái khi người dùng mở rộng và ký hợp đồng với các cửa sổ.