Thiết kế mẫu cho hệ thống quy tắc?

Là một dự án vui vẻ nhanh chóng, tôi đã thử viết một trò chơi solitaire. Nhưng khi viết lên các hệ thống quy tắc, tôi cảm thấy bẩn , bởi vì mã của tôi cảm thấy hoàn toàn không có cấu trúc và không thể giải thích được , chủ yếu là do logic trò chơi của tôi là mã spaghetti hoàn chỉnh.

Tôi đã gặp phải vấn đề này trước đây và luôn cảm thấy lúng túng khi viết phần này của chương trình của mình, vì vậy tôi tự hỏi, có bất kỳ thử nghiệm và thực hành tốt nhất nào khi xác định quy tắc trong trò chơi không?

Tôi không nghĩ rằng có một giải pháp độc đáo vì rất nhiều sự điều khiển đến từ vấn đề cụ thể.

Bạn có thể sử dụng mẫu Trình điều khiển Chế độ xem Mô hình: điều này chuyển (giới hạn) vấn đề của bạn sang "cách thực hiện một hành vi trên bộ điều khiển", một beahaviour luôn tuân theo các quy tắc.

Trừ khi chúng ta đang nói về các quy tắc rất đơn giản, cách bạn tổ chức chúng đặt ra một vấn đề về tính biểu cảm . Bạn luôn phải đối mặt với những yêu cầu mâu thuẫn là đơn giản (có cấu trúc) và có tính biểu cảm (viết quy tắc vui vẻ).

Sử dụng MVC đơn giản hóa công việc của bạn vì mô hình chính thức hóa một trạng thái tức là bối cảnh trong đó các quy tắc được thi hành.

Nói rằng, bạn có thể thấy hữu ích khi triển khai Bộ điều khiển bằng cách sử dụng mẫu Chiến lược và / hoặc mẫu Trạng thái để tạo một hành vi phức tạp theo các hành vi có thể chuyển đổi đơn giản hơn. Một mô hình chuỗi-of-resposibility có thể giúp bạn thể hiện quy tắc trong khi một máy nhà nước nên được sử dụng một cách cẩn thận vì nó "nhà nước" một phần trùng lặp ý nghĩa của mô hình "nhà nước".

Sử dụng mẫu Lệnh trong Bộ điều khiển có thể hữu ích để giảm cả độ phản hồi của Bộ điều khiển (Lệnh biết cách xử lý mô hình) và giúp dễ dàng thêm các chức năng hoàn tác / làm lại trong Bộ điều khiển.

Ở mức độ nào, bạn nên thử sử dụng các mẫu thiết kế làm hướng dẫn: chúng rất hữu ích để tránh phát minh lại bánh xe, đặc biệt là bánh xe vuông, nhưng không phải mọi giải pháp của vấn đề đều bao gồm một loạt các bánh xe (tròn) ghép lại với nhau.

Tôi không chắc chắn về việc tốt nhất hay thậm chí là tốt nhưng tôi thường sử dụng mẫu Observer . Nó làm việc đủ tốt cho tôi.

Trừ khi bạn đã thực hiện công việc nhiều lần trước đây, bạn sẽ luôn kết thúc với mã spaghetti. Trên thực tế, tại thời điểm này, bạn chỉ mới bắt đầu: những gì bạn có là bản phác thảo sơ bộ của một thông số sơ bộ. Kiểm tra một số lời khuyên khác ở đây và làm một số viết lại nghiêm túc. Và sau đó viết thêm một vài lần nữa, và sau đó .... Cá nhân tôi không bao giờ chắc chắn liệu tôi có thể tạo được mã của mình thành hình dạng thực sự tuyệt vời hay chỉ bị bệnh khi viết lại nó, nhưng cuối cùng tôi dường như đã hiểu đúng.

Giải quyết vấn đề từ hai đầu. Cố gắng để có được thiết kế tổng thể để có ý nghĩa và chọn các bộ phận nhỏ xử lý các công việc đơn giản và làm cho chúng đúng. Sau đó cố gắng làm việc theo cách của bạn từ cả hai đầu đến giữa. Và sau đó làm việc từ giữa trở lại về cả hai đầu. Rồi từ trên xuống, rồi từ dưới lên. Sau đó lặp lại toàn bộ quá trình.

Về cơ bản, những gì bạn có là một bộ sưu tập các lớp. Xem xét lớp A. Nếu lớp A được xây dựng tốt, thì các lớp sử dụng nó sẽ tự động hoạt động tốt hơn, dù chúng tốt hay xấu. Nếu sử dụng lớp Một lớp học tốt, những lớp học đã qua sử dụng sẽ làm được nhiều hơn, tuy nhiên tốt hay xấu họ đang có. Vì vậy, tổ chức các lớp học của bạn tốt nhất có thể, sau đó đảm bảo mỗi lớp là lớp tốt nhất có thể.

Điều quan trọng là phải làm cho nó đúng như bạn có thể. Mã xấu sẽ ám ảnh bạn cho đến ngày bạn vứt nó đi. Với phần mềm, một chút đánh bóng thêm luôn được đền đáp. (Trừ khi không có ai kết thúc bằng cách sử dụng mã ....)

Tóm lại: kiểm tra lời khuyên thực tế được đưa ra trong các câu trả lời khác, sau đó viết lại mã của bạn cho đến khi bạn nhận được thứ bạn thích.