2009-12-26 74 views
7

Tôi đã tạo một ứng dụng Swing khá đơn giản về chức năng. Tuy nhiên mã mà nó bao gồm trở nên khá lớn và rất lộn xộn theo ý kiến ​​của tôi. Tất cả các thành phần swing và hành động là trong một tập tin. Vì vậy, ví dụ nếu tôi đã làm cho một ứng dụng thậm chí lớn hơn với nhiều chức năng mã sẽ được khá khó khăn để đi qua.câu hỏi chung về Java Swing

Vì vậy, câu hỏi của tôi là cách tạo cấu trúc mã tốt. Hoặc nếu có một trang web tốt tôi có thể đọc về nó, và nếu có thể một số ví dụ mã. Tôi đã kiểm tra hướng dẫn của Sun về Swing, nhưng đó là một ví dụ khá đơn giản mà họ đã thể hiện.

CẬP NHẬT: Tôi đã cân nhắc một lúc và kiểm tra một số ví dụ. Tôi không biết liệu tôi có đúng mẫu MVC hay không. Dù sao ý tưởng của tôi là tách riêng từng JFrame thành tệp lớp của riêng họ. Sau đó tôi có một MainFrame là cửa sổ chính cho ứng dụng. Từ đó JFrame tôi tạo ra một ví dụ của mỗi JFrame tôi có. Và gọi những khung đó từ MainFrame với các hành động. Tôi không biết đây có phải là một ý hay hay không. Tuy nhiên nó làm cho mã đáng kể dễ đọc hơn.

Dưới đây là một ví dụ về làm thế nào tôi có nghĩa là

class Main implements ActionListener { 

    private JFrame frame = new JFrame(); 
    private JButton button1 = new JButton(); 
    private JPanel panel = new JPanel(); 

    private FirstFrame frame1 = new FirstFrame(); 
    private SecondFrame frame2 = new SecondFrame(); 
    private ThirdFrame frame3 = new ThirdFrame(); 

    public Main() { 
     button1.addActionListener(this); 
    } 

    public createGUI() { 
     frame.setTitle("Main"); 
     frame.setSize(400,300); 
     panel.add(button); 

     frame.setVisible(true); 
     frame.setLocationRelativeTo(null); 
    } 

    public static void main(String args[]) { 
     new Main().createGUI(); 
    } 

    @Override 
    public void actionPerformed(ActionEvent e) { 
     if(e.getSource() == button1) 
     { 
      frame1.enable(); 
     } 
    } 
} 
+1

Câu hỏi hay! Tôi đã cân nhắc điều này một lúc. –

Trả lời

8

Sử dụng Model-View-Controller design pattern. Nó liên quan đến tách sử dụng mã giao diện từ logic kinh doanh.

EDIT:

Như OP được tìm mã có tổ chức chứ không phải là thiết kế linh hoạt, tôi đã gỡ bỏ các thiết kế phần NetBeans UI từ câu trả lời của tôi.

+0

Tôi đã sử dụng addons giao diện người dùng trực quan cho Eclipse, nhưng kinh nghiệm của tôi là nó sẽ thêm rất nhiều mã phế liệu. Đây có phải là trường hợp tương tự cho Netbeans? – starcorn

+0

tuy nhiên, nếu có tài nguyên để đọc, tôi thích học mã theo cách thủ công cũng như – starcorn

5

Tổ chức mã giao diện người dùng của bất kỳ kích thước đáng kể nào là một vấn đề đáng ngạc nhiên khi viết về nó, xem xét rằng mọi ứng dụng đều có cùng một vấn đề. Có một số kỹ thuật có thể trợ giúp:

  1. Tái cấu trúc - để làm sạch sau khi mã bị xóa.
  2. Mẫu Bộ điều khiển chế độ xem mô hình - để phân tách mối quan tâm.
  3. Thiết kế OO - sử dụng nhiều lớp học nhỏ, hợp tác thay vì các đoạn mã lớn.
  4. "Trên sự kiện Làm hành động" - thành ngữ để tách các hành động khỏi chế độ xem.
  5. Mô hình thành phần UML - trực quan hóa các khái niệm thiết kế phía trên cấp lớp.
  6. Nguyên tắc đảo ngược phụ thuộc - tổ chức các phụ thuộc mã.

Các kỹ thuật thiết kế cơ bản đã được sử dụng trong một thời gian ngắn và được hiểu rõ, nhưng áp dụng các kỹ thuật trên quy mô lớn hơn là một cái gì đó dường như được thiết kế riêng cho từng ứng dụng.

Một cách tiếp cận mà tôi đã thấy áp dụng một cách hiệu quả là tách riêng các Sự kiện, Người nghe, Hành động, v.v. thành các lớp của riêng họ và tổ chức chúng thành từng gói hoặc sử dụng quy ước đặt tên nhất quán trên các gói để thành phần và các lớp liên quan của nó có thể dễ dàng nhận dạng (XDialog, XDialogMouseListener, XDialogCancelAction, vv).

Một cách tiếp cận khác là xem xét một số ứng dụng nguồn mở lớn (Eclipse, Firefox, ...) và xem cách chúng tổ chức mã GUI của chúng.

+0

Làm cách nào để tách mã? Vì tôi có một số quan điểm. Mà phụ thuộc vào hành động, do đó tôi không thể tách nó ra. – starcorn

+0

Nếu bạn tách một hành động khỏi một chế độ xem và nó không còn biên dịch, thì bạn có thể giới thiệu các phương thức bổ sung để cho phép các lớp riêng biệt truy cập vào chức năng bị thiếu. Các phương thức bổ sung cần được tổ chức thành các giao diện. Giao diện có thể được khai báo với quyền truy cập cấp gói nếu các phương thức không được công bố công khai. – richj

+0

Trong chế độ xem MVC thường sẽ không phụ thuộc vào hành động, mặc dù trong chế độ xem MV2 và bộ điều khiển có thể được kết hợp chặt chẽ hơn. Giới thiệu giao diện cho phép bạn sử dụng Nguyên tắc đảo ngược phụ thuộc để đảo ngược hướng của bất kỳ phụ thuộc nào đi sai hướng. – richj

2

Tôi có xu hướng kéo nhiều chức năng không liên quan đến GUI ra khỏi các thành phần Swing càng tốt. Điều đó có nghĩa là bạn có thêm một số hướng dẫn. Tuy nhiên:

  1. lớp Swing không làm gì nhưng tương tác GUI
  2. các chức năng kinh doanh là dễ dàng hơn nhiều để kiểm tra và kết quả duy trì

Tôi không nhất thiết phải nói về một mô hình MVC đầy đủ (mặc dù đó không phải là điều xấu). Đó là vấn đề về tổ chức lớp/gói.

+0

+1 cho chủ nghĩa thực dụng, tôi cũng làm như vậy. Đặc biệt với một nhà thiết kế giao diện đồ họa như JFormDesigner, nó làm cho nó dễ dàng thêm hành động và xử lý hành động cho các nút, v.v. Nó có ý nghĩa để có tất cả những gì trong một lớp duy nhất, gọi là các lớp trợ giúp. Ví dụ, hành động in của tôi chỉ là một trình bao bọc gọi PrintTask(). Print (myJob) mới. PrintTask là một lớp riêng biệt (không phải bên trong), không có gì liên quan đến GUI. –

1

Điều cần lưu ý là lập trình UI giống như các loại lập trình khác. Đừng nghĩ rằng nó là đặc biệt và bạn có thể bỏ qua thực hành hợp lý. Thật không may, hầu hết các mã hướng dẫn là rất xấu, và mã trong sản xuất có lẽ có xu hướng tồi tệ hơn nhiều.

Những điểm mấu chốt:

  • Sử dụng một thiết kế lớp. Đó không chỉ là sự bền bỉ-kinh doanh-ui. Chia nhỏ hơn. Ví dụ: một lớp bố cục không được tạo thành phần (trừ bố cục, thường là JPanel s).
  • Ưu tiên thành phần thừa kế. Có rất ít điểm phân loại các lượt thích của JFrameJPanel, vì vậy đừng làm điều đó.
  • Giữ giao diện người dùng mỏng. Ví dụ, các trình kết xuất đồ họa nên có rất ít logic trong chúng. Đối với một điều này làm cho thử nghiệm dễ dàng hơn nhiều (đó là thử nghiệm tự động, thử nghiệm quy mô lớn bằng tay là phản tác dụng).