GUI mã vạch hoặc sử dụng công cụ gui-designer

Question

Tôi muốn nghe một số ý kiến ​​trên tay mã hóa GUI của bạn như một cách thường làm khi sử dụng Java hoặc Qt với C++, so với sử dụng công cụ gui-designer? Ví dụ về các công cụ thiết kế GUI sẽ là MFC GUI-designer, Qt designer, Interface Builder (Apple).

Tôi từng là người hâm mộ mã hóa tay nhưng từ kinh nghiệm gần đây tôi đã chuyển đổi. Vấn đề tôi đã thấy với mã hóa tay là nó khá nhanh và linh hoạt để viết các GUI nhưng một khi bạn cần thực hiện một thay đổi đối với GUI được viết từ lâu thì nó có thể rất khó. Tìm kiếm yếu tố phù hợp trong bảng điều khiển lớn có thể khó khăn.

Vấn đề thứ hai là nó làm cho nó quá dễ dàng để thêm rất nhiều logic trong việc tạo ra GUI và mã bố trí. Tôi thường xuyên phải tiếp tục bảo trì mã GUI vốn rất khó sử dụng lại vì hành vi của nó được trộn lẫn với ngoại hình và cách bố trí trộn lẫn hành vi của nó thường làm cho lớp học rất lớn và khó hiểu.

Sử dụng công cụ thiết kế GUI buộc phải phân tách rõ ràng hơn giữa giao diện và logic trong chế độ xem của tôi.

Answer 1

Tôi cảm thấy mạnh mẽ rằng bạn nên sử dụng trình tạo giao diện thay vì mã hóa bằng tay GUI. Như trong câu hỏi được đề cập, nó là một sự tách biệt rõ ràng hơn và một khi một cái gì đó phải được chỉnh sửa thì nó dễ dàng hơn nhiều.

Các Qt Designer có tính năng này để tạo ra một lớp ra của một tập tin .ui ₁₎, nhưng tôi nghĩ rằng không sử dụng tính năng này là cách tốt nhất, vì điều này tạo ra chỉ hơn được mã hóa mà không nên tồn tại ở tất cả các . Vấn đề tốc độ tạo cửa sổ từ một tệp .ui là không đáng kể vì cửa sổ phải được tải chỉ một lần.

Đây là PyQt, nhưng một cái gì đó tương tự có thể có trong C++:

class SelectDateDialog(QDialog): 
    def __init__(self): 
     QDialog.__init__(self) 
     uic.loadUi("resources/SelectDate.ui", self) 

Về cơ bản này có tác dụng tương tự như bao gồm tất cả UI-mã của bạn vào các phương pháp __init__(), nhưng giao diện người dùng được gần như hoàn toàn tách ra khỏi mã.

¹⁾.ui file là file XML mô tả một giao diện người dùng

Answer 2

Điều đó tùy thuộc vào hoàn cảnh thực tế. Tôi nghĩ cả hai đều có vị trí của họ, và tôi thường sử dụng một phương pháp lai.

Luôn có một số thứ mà trình xây dựng GUI không thể thực hiện (ví dụ: thiết lập màu thành hằng số UIColor trong Bộ dựng giao diện). Mặt khác, hầu hết các công việc giao diện người dùng khá lộng lẫy (ví dụ như thêm nhãn tĩnh).

Tôi thích làm những thứ trần tục hơn trong trình tạo GUI và các nội dung thú vị khác trong mã.

Ngoài ra, đôi khi tôi thấy mình đang chỉnh sửa XML được tạo bởi trình tạo GUI (Trình tạo giao diện và trong trường hợp của tôi) bằng tay.

Answer 3

Vui đủ nó đã đi theo cách khác vòng cho tôi. Nói theo quan điểm của Winforms, mã được tạo ra bởi nhà thiết kế khá ồn ào, với một phần tư hoặc một nửa tất cả các cài đặt thuộc tính thực sự cần thiết. Kiểm soát khá lớn cũng là một sự cám dỗ khi làm việc với một nhà thiết kế. Thay đổi một số thứ bậc của các điều khiển trong trình thiết kế Winforms là một cơn ác mộng trong mắt tôi.

Trong dự án cuối cùng của tôi, tôi đã tạo các API bổ sung để thiết lập bộ tách trong biểu mẫu, thanh công cụ, menu, thanh công cụ, v.v. theo cách khai báo. Đây là như vậy mà họ sẽ tiếp tục thực thi tách mối quan tâm.

Tôi cũng cố gắng dựa nhiều hơn vào các tính năng bố cục tự động vốn được cho là đẹp hơn rất nhiều trong WPF nhưng cũng có thể đi theo một số cách trong Windows Forms.

Answer 4

Quan điểm của tôi về vấn đề này: 1. Mã GUI Hand-mã là nhiều hơn nữa tái sử dụng 2. Các vấn đề Layout là đơn giản với thiết kế

Answer 5

Tôi mạnh mẽ sẽ khuyên bạn sử dụng giao diện Builder trên OS X. Làm nó bằng cách tay là tốt nếu bạn muốn tìm hiểu, nhưng bạn sẽ tiết kiệm cho mình rất nhiều đau đầu bằng cách sử dụng nó trên các dự án thực tế. Nó thực sự là khá mạnh mẽ.

Đối với Java và C++, nó phụ thuộc vào những gì bạn đang làm và trên nền tảng nào. Đối với các ứng dụng đơn giản, bạn có thể thoát khỏi mà không bao giờ nhìn thấy mã giao diện người dùng. Tuy nhiên, đối với các ứng dụng phức tạp và các ứng dụng khách phong phú, bạn thường phải thực hiện một số mã bằng tay.

Answer 6

tôi sẽ luôn tay mã thiết kế GUI nơi không có tiêu chuẩn (hoặc de-facto tiêu chuẩn) ngôn ngữ đánh dấu GUI (như với Java). Lý do cho điều này là tôi đã tìm thấy rằng chúng ta trong một công cụ thiết kế GUI builder sẽ buộc bạn sử dụng một IDE cụ thể. Theo thời gian, IDE tốt nhất cho thiết kế GUI và/hoặc viết mã sẽ thay đổi và mỗi nhà phát triển sẽ được tự do lựa chọn bất kỳ IDE nào họ cảm thấy thoải mái nhất với.

Nơi tôi làm việc tại thời điểm này, chúng tôi có rất nhiều GUI cũ được viết bằng cách sử dụng NetbeansMatisse GUI builder (chống lại lời khuyên của tôi tại thời điểm :-). Hiện tại, chúng hầu như không thể duy trì được vì tất cả các nhà phát triển đều thích hoặc là IntelliJ IDEA hoặc Eclipse làm IDE của họ. Nó không phải là thực tế hoặc khả thi để các nhà phát triển khởi động Netbeans chỉ để sửa đổi bố trí GUI (mọi người không giữ các định nghĩa dự án Netbeans đồng bộ, vv).

Một điểm khác là tổng thời gian viết mã bố cục GUI có lẽ chỉ chiếm 5% tổng số nỗ lực phát triển của một dự án cụ thể. Ngay cả khi bạn mất hai lần để tự viết mã, điều này không dịch nhiều tiền phí trong một chương trình lớn. Và đó là một mức giá nhỏ để trả cho khả năng bảo trì lâu dài.

Miễn là bạn đã rõ ràng về việc tách logic bố cục GUI khỏi logic nghiệp vụ, tôi không tin rằng bất kỳ điều gì cũng bị hậu quả. Không ai ở đây sử dụng các nhà xây dựng GUI nữa!

Answer 7

Tôi làm điều đó bằng tay, dễ dàng hơn nhiều khi trộn những thứ xung quanh và sử dụng lại các bảng bên trong ứng dụng (một số bảng có thể xuất hiện ở một số nơi).

Sử dụng một nhà thiết kế hoạt động khi bạn ở trong một nhóm các nghệ sĩ có nghĩa vụ phải làm GUI.

Tìm phần tử phù hợp trong bảng lớn có thể khó khăn.

?? Tôi chưa bao giờ thấy điều đó.

Answer 8

Tôi có xu hướng nghĩ rằng câu trả lời đúng tùy thuộc vào nền văn hóa của nền tảng mục tiêu. Trên OS X, Interface Builder là một phần không thể tách rời của chuỗi công cụ mà rất khó để tránh nó.

Trong Java (awt hoặc swing), điều ngược lại thực sự đúng. Không có hỗ trợ toolchain cho việc này.

Thực sự, cách bạn có thể biết, là cách các công cụ tạo ra kết quả đầu ra của chúng. Interface Builder tạo ra các tệp định dạng .nib cụ thể cho cách Cocoa đặt các điều khiển trên màn hình. Nó hiểu về cơ bản là một định dạng đánh dấu giao diện. Java không có khái niệm tương tự như vậy. Tất cả mọi thứ là một lớp biên dịch, và có nhiều khó khăn hơn để có được kết quả thuận tiện.

GTK +, khi được kết hợp với glade, dường như tạo ra sự cân bằng hợp lý giữa hai loại.

Answer 9

Không có gì ngăn cản việc trộn lẫn hai cách tiếp cận. Tôi thường tạo bố cục chính của biểu mẫu trong trình thiết kế GUI (vì nó nhanh và bạn thấy những gì bạn đang làm) và đặt một hoặc nhiều bảng sau đó được điền bằng mã. Điều này đặc biệt hữu ích khi GUI phải thích nghi với các tình huống cụ thể - ví dụ, nếu GUI phải thay đổi theo phần cứng nào được kết nối.

Trong mọi trường hợp, điều quan trọng nhất thực sự là giữ GUI và logic ứng dụng riêng biệt.

Answer 10

tay mã hóa có thể tốt nếu bạn muốn có một số tính năng phi tiêu chuẩn bao gồm trong bạn UI. Bạn có tính linh hoạt hơn, nhưng bạn sẽ cần phải đầu tư thêm thời gian để tạo ra một giao diện tốt, bởi vì Java/C++ là ngôn ngữ không có nghĩa là nhắm mục tiêu thiết kế giao diện người dùng. Nếu bạn có quyền kiểm soát sửa đổi, bạn có thể xem lịch sử thay đổi, một thứ không thể thực hiện được với thiết kế sử dụng định dạng nhị phân hoặc định dạng xml không thân thiện với RCS.

Ngày nay, hầu hết các công cụ có sẵn để thiết kế trực quan giao diện người dùng đều thiếu một số tính năng. Chúng không đủ linh hoạt, một số tính năng chỉ có thể được mã hóa chúng. Cũng trong một số trường hợp, mã được tạo ra không thực sự thân thiện với con người, và nếu bạn sửa đổi bằng tay, bạn có thể không còn có thể tiếp tục sử dụng trình thiết kế. Tuy nhiên, thiết kế có thể thực sự tiết kiệm thời gian nếu thiết kế đơn giản, và chúng tôi hy vọng các nhà thiết kế sẽ được cải thiện trong tương lai, nhưng tôi sẽ không giữ chiều rộng. Kết luận của tôi là nếu bạn cần sự linh hoạt ngày hôm nay, bạn sẽ phải mã hóa bằng tay giao diện, nếu bạn muốn một cái gì đó đơn giản và nhanh chóng thì nhà thiết kế là sự lựa chọn tốt nhất. Có lẽ trong tương lai các nhà thiết kế sẽ mạnh hơn, hoặc có lẽ sẽ có những ngôn ngữ mới chuyên về thiết kế giao diện người dùng sẽ phù hợp hơn để sử dụng trong C++/Java, giống như XUL hoặc XAML.

Answer 11

Nếu bạn đang thiết kế ứng dụng doanh nghiệp có nhiều biểu mẫu nhập và dữ liệu dạng bảng, viết mã cho giao diện người dùng của bạn nhanh hơn và dễ bảo trì hơn so với sử dụng trình thiết kế giao diện người dùng. Trong các loại ứng dụng đó, hầu như không bao giờ cần đặt chính xác một phần tử ở vị trí được xác định trước trên màn hình, trong khi đó, có rất nhiều sự lặp lại và các quy ước thiết kế có thể được tách ra thành các phương thức riêng biệt.

Ví dụ như hộp thoại tùy chọn Eclipse hoặc OpenOffice. Có một loạt các danh mục và một loạt các tùy chọn khác nhau để đặt cho từng danh mục. Nếu bạn phải làm một cái gì đó kích thước đó, tay thiết kế mỗi màn hình là một nhiệm vụ trần tục. Cách tiếp cận tốt hơn nhiều là viết mã sẽ tạo ra các phần tử giao diện người dùng trực tiếp, từ dữ liệu miền được cung cấp, theo một số quy ước và mặc định.

Tôi không thấy cách sử dụng một nhà thiết kế tạo điều kiện tách biệt tốt hơn, cũng như cách nhận thức được sự tách biệt sẽ giúp ích gì, vì bạn đã giữ logic nghiệp vụ của mình ra khỏi giao diện người dùng.

Và cuối cùng, nếu bạn đang sử dụng Java, hãy nhớ xem MigLayout. Nó hoạt động với Swing và SWT, cú pháp của nó rất súc tích và rõ ràng, và nó có một chế độ gỡ lỗi không thể tin được.