Bạn bắt đầu viết lớp GUI trước hay ngược lại?

Tôi muốn viết chương trình Java đầu tiên của mình, ví dụ như Danh bạ và tôi tự hỏi phải làm gì trước tiên. Câu hỏi của tôi là tôi nên viết các lớp GUI trước hay sử dụng các lớp trước? Tôi là nhà phát triển cơ sở dữ liệu và muốn biết thực hành tốt nhất trong việc xây dựng chương trình.

Về lý thuyết, có ít nhất năm phương pháp khả thi.

Từ trên xuống:

Bắt đầu với UI mock-shot hoặc nguyên mẫu giấy. Biến chúng thành các hộp thoại thực và hoạt động theo cách của bạn từ trình xử lý nút và các điều khiển khác thông qua logic và đến cơ sở dữ liệu.

Từ dưới lên:

Bắt đầu với các cấu trúc dữ liệu (có thể là lược đồ cơ sở dữ liệu). Sau đó thêm logic (mô hình hóa các quy trình trong thế giới thực); cuối cùng, giao diện người dùng của bạn chỉ là một giao diện để kích hoạt logic và hiển thị kết quả.

Logic đầu tiên:

Bắt đầu với logic chương trình, thực hiện truy cập dữ liệu và giao diện người dùng thô sơ khi cần. Sau đó chính thức hóa và làm cứng cấu trúc dữ liệu, và cuối cùng xác định UI đúng cách.

Gặp ở giữa:

Bắt đầu với lược đồ cơ sở dữ liệu và giao diện người dùng và đồng thời làm việc tại điểm mà chúng gặp nhau. Với phương pháp này, logic đến sau cùng.

Mở rộng theo chiều ngang:

Bắt đầu bằng cách xác định số lượng chức năng tối thiểu tuyệt đối sẽ làm điều gì đó thú vị và triển khai toàn bộ ngăn xếp (cấu trúc dữ liệu, logic và giao diện người dùng) cho phần này. Nó có thể chỉ là một chu trình CRUD cơ bản với hộp thoại chỉnh sửa đơn giản cho chỉ một thực thể. Sau đó bắt đầu thêm nhiều tính năng, triển khai toàn bộ ngăn xếp cho từng tính năng (do đó là 'ngang').

Mỗi cái đều có ưu và nhược điểm.

Từ trên xuống cung cấp cho bạn một cái gì đó có thể nhìn thấy sớm trong quá trình và cho phép bạn kiểm tra thiết kế chức năng của mình với các bên liên quan - ảnh giả thường cho người dùng biết nhiều hơn về một thiết kế so với sơ đồ hoặc tường văn bản.

Từ dưới lên cho bạn cơ hội thiết kế lược đồ cơ sở dữ liệu vững chắc trước khi bạn cam kết với bất cứ điều gì; do lược đồ cơ sở dữ liệu nổi tiếng là khó sửa đổi một khi được phát hành, bạn muốn làm cho phần này đúng - tác động của việc sửa đổi UI nhỏ hơn nhiều và tạo ra các lỗi ít nghiêm trọng hơn.

Logic trước tiên có nghĩa là bạn có thể kiểm tra logic trước khi dành thời gian nghiêm túc cho cơ sở dữ liệu và bản trình bày, điều này đặc biệt thú vị nếu logic của bạn sẽ thực sự phức tạp.

Gặp gỡ ở giữa kết hợp các lợi thế của từ dưới lên và từ trên xuống, nhưng bạn sẽ phải nhảy qua lại giữa hai nhiệm vụ và bạn có nguy cơ kết thúc bằng logic phức tạp hơn mức cần thiết vì hai đầu của bạn đừng gặp nhau một cách tự nhiên.

Mở rộng theo chiều ngang phù hợp với quy trình lặp lại và có một ưu điểm nữa là, nếu bạn ưu tiên tốt, bạn sẽ có một ứng dụng hoạt động vào bất kỳ thời điểm nào, vì vậy nếu bạn không đưa ra thời hạn, bạn sẽ có một phiên bản có Ít tính năng hơn, nhưng vẫn đầy đủ chức năng, trái ngược với phiên bản có cơ sở dữ liệu hoàn chỉnh, nhưng không có giao diện người dùng nào cả.

Vì vậy, cái nào bạn chọn phụ thuộc vào phong cách cá nhân của bạn, và hoàn cảnh.

Nếu bạn là nhà phát triển cơ sở dữ liệu, tôi nghĩ bạn nên bắt đầu với một mô hình dữ liệu và tạo một lớp trừu tượng tốt để dễ xác định giao diện người dùng của bạn (có thể là GUI hay không).

Cá nhân, tôi sẽ phân tích mối quan tâm của người dùng và đi từ đó. Lý tưởng nhất, khía cạnh của ứng dụng đòi hỏi nhiều công việc nhất nên bắt đầu trước.

Trong kịch bản này, tôi tập trung vào các giả lập UI làm trọng tâm chính. Khách hàng đã bày tỏ mối quan tâm về việc hỗ trợ một nhóm người dùng cuối đa dạng, đặc biệt là những người có trở ngại về thị giác và phân phối hệ thống trên các dòng văn hóa. Do đó, trong khi có một hệ thống chức năng và ổn định sẽ rất quan trọng, tầm quan trọng của việc có một giao diện cho phép người dùng dễ dàng hoàn thành công việc là tiền lệ.

Kịch bản này sẽ khiến tôi tập trung vào logic miền. Khách hàng đã yêu cầu một hệ thống với các tương tác kinh doanh phức tạp. Nó sẽ lưu trữ một lượng lớn cấu trúc dữ liệu phức tạp. Do đó, công việc ban đầu khám phá và thực hiện logic nghiệp vụ với lưu trữ nguồn dữ liệu sẽ dẫn đến một dự án thành công.

Nếu hệ thống là một dự án cá nhân, thì hãy tập trung vào những gì bạn muốn học từ dự án. Nếu tôi đang thử một công nghệ mới, tôi cố gắng tập trung vào một đột biến nhỏ với nó và cô lập chính công nghệ đó để tôi có thể nắm bắt tốt hơn cách thức hoạt động của nó. Tuy nhiên, một dự án cá nhân trải qua tất cả các giai đoạn sẽ có lợi ích giúp bạn chuẩn bị tốt hơn cho các dự án "thực sự". Trong trường hợp đó, tôi sẽ phác thảo một số mục tiêu chính và sử dụng chúng làm bước đệm. Nếu ứng dụng danh bạ điện thoại này là một dự án cá nhân của bạn, tôi sẽ khuyên bạn nên làm việc thông qua UI trước tiên. Là một nhà phát triển cơ sở dữ liệu, tôi giả định rằng bạn biết cách kết nối cơ sở dữ liệu với logic miền và cách viết logic miền, nhưng chưa khám phá nhiều công nghệ UI; do đó, làm việc trên UI sẽ có lợi cho việc học của bạn hơn là bắt đầu từ nguồn dữ liệu hoặc logic miền.

Bắt đầu với một phần của dự án mà bạn thấy thú vị nhất. Nếu bạn bắt đầu với phần bạn không thích, bạn có thể bỏ cuộc trước khi bạn tiến bộ. Nơi bạn bắt đầu chủ yếu là vấn đề ưu tiên, vì vậy bạn cũng có thể chọn những gì bạn muốn làm việc nhất.

Bắt đầu với tên miền hoặc những gì bạn gọi là 'lớp học'. Kiểm tra nó độc lập với việc thực hiện UI của bạn. Bằng cách đó, bạn sẽ hiểu rõ hơn về cách ứng dụng của bạn hoạt động (hoặc nên hành xử), cách logic diễn ra bất kể khung UI, MVC hay gì, công cụ, phong cách bạn dự định sử dụng cuối cùng.

Liên kết bản thân với một triển khai UI cụ thể thường là một ý tưởng tồi. Tôi không nói rằng bạn không nên xem xét nó trước. Tôi đang nói rằng ứng dụng của bạn không nên phụ thuộc vào nó. Giao diện người dùng có xu hướng thay đổi RẤT NHIỀU trong quá trình của dự án và nếu tên miền của bạn được gắn với nó thì bạn cũng sẽ thay đổi tên miền của mình rất nhiều.

Hầu như mọi người sẽ có một phương pháp khác nhau để phát triển phù hợp với phong cách của họ. Ví dụ, một người có thể thấy rằng việc thiết kế GUI của họ dễ dàng hơn nếu họ đã xác định kiến ​​trúc cơ bản và lưu trữ dữ liệu. Tuy nhiên, một người khác có thể thấy rằng chơi xung quanh với GUI và nhận bản nháp ban đầu có thể giúp họ tổ chức tốt hơn hệ thống lưu trữ của họ và mã hóa chương trình của họ theo cách có tổ chức hơn. Nhiệm vụ trước khi bạn sẽ là tìm ra phương pháp nào (hoặc có thể là một số kết hợp của cả hai) phù hợp nhất với bạn. Đối với tôi, tôi thích thực hiện một bản mô phỏng ban đầu về những gì tôi nghĩ GUI sẽ trông như thế nào, sau đó bắt đầu làm việc với các đai ốc và bu lông của ứng dụng. Khi tôi đã hoàn thành, tôi thường quay lại và thay đổi GUI khi cần.

Đây là một dự án khá đơn giản mà tôi nói nó không quan trọng. Trên nhiều dự án mặc dù sẽ không rõ ràng chính xác cách bạn muốn GUI nhìn và vận hành, và một khi bạn thực hiện nó, ai đó có thể yêu cầu bạn thay đổi nó. Thật tốt khi tạo ra các bản mô phỏng GUI nhanh chóng để bạn hoặc bất kỳ ai chịu trách nhiệm có thể đưa ra quyết định cụ thể về giao diện của nó và sau đó điều này sẽ giúp bạn thấy một số dữ liệu tương quan mà bạn cần theo dõi bạn có thể không nhận thấy rằng bạn đã bắt đầu với thiết kế dữ liệu.

Quan trọng hơn, bạn KHÔNG muốn thiết kế dữ liệu của mình điều khiển giao diện người dùng. Nói một cách tương đối, tôi tin rằng việc sửa lỗi triển khai GUI kém dễ dàng hơn nhiều so với sửa lỗi triển khai dữ liệu kém. Vì vậy, tôi chắc chắn bỏ phiếu để bắt đầu với GUI.

Và bản thân tôi là một anh chàng cơ sở dữ liệu, chỉ là fyi.