Thiết kế cân nhắc cho menu cấu hình trên hệ thống nhúng

Tôi đang làm việc trên một hệ thống nhúng có giao diện với người dùng với một số nút và màn hình đồ họa nhỏ.

Như một lưu ý phụ: Vì tôi đang ở trên một hệ thống nhúng, tôi muốn ngăn việc cấp phát bộ nhớ động càng nhiều càng tốt. Một cái gì đó như std :: vector thậm chí không có sẵn.

Tôi cần triển khai menu cấu hình bằng cấu trúc menu lồng nhau cổ điển như thế này:

Level A Node 1
 -> Level B Node 1
    -> Level C Node 1
 -> Level B Node 2
 -> Level B Node 3
Level A Node 2
Level A Node 3

Tôi rất không chắc chắn về cách tiếp cận tốt nhất ở đây. Tôi đọc về một số cách để tiếp cận một cái gì đó như thế này như sử dụng Mô hình tổng hợp. Tuy nhiên, tôi luôn va vào thứ gì đó trông có vẻ "trên giấy" nhưng dường như là một mớ hỗn độn để thực hiện.

Suy nghĩ chung của tôi là có một cái gì đó một MenuNodelớp biết về các nút phụ và nút cha của nó khi khởi tạo. Một Menulớp có thể xử lý điều hướng nút và xử lý. Rõ ràng, mọi MenuNodephải thực hiện / thực hiện hành vi cụ thể như:

Báo cáo Menunhững gì nó muốn hiển thị (bố cục / định vị thực tế không phải là mối quan tâm của MenuNode)
Phản ứng với đầu vào của người dùng (như nhấn nút để tăng / giảm / chuyển đổi giá trị)
Truy cập giá trị thực tế của lãi suất (chúng nằm trong một ApplicationSettingslớp)

Điều gì sẽ là cách tốt nhất để thực hiện điều này?

Sử dụng một MenuNodelớp cơ sở (trừu tượng) và tạo một lớp con cho MỌI mục nút menu. Trong quá trình khởi tạo tôi có thể cung cấp một con trỏ tới ApplicationSettingshoặc các phụ thuộc khác mà nó có thể cần. Bằng cách nào đó, cảm thấy sai lầm khi tạo ra 10 lớp dẫn xuất trong đó mỗi lớp sẽ được kích hoạt chỉ một lần.
Sử dụng cùng một MenuNodelớp cho mọi nút và thực hiện chức năng thông qua các cuộc gọi lại đến các chức năng miễn phí. Từ những gì tôi đọc khá phổ biến đến "ghép" các hàm miễn phí với các đối tượng. Tuy nhiên, nó cảm thấy như nó sẽ làm phức tạp mọi thứ. Đối với mỗi thành viên có thể có, như ReportButtonPress () hoặc một cái gì đó, tôi sẽ phải cung cấp cuộc gọi lại để thực hiện thực tế trong quá trình khởi tạo.
Tôi chắc chắn có một cái gì đó tôi đang nhìn ở đây.

— Rev1.0
nguồn

Tôi đã thực hiện các menu tương tự để nhúng bằng C trong quá khứ và đây là điều lớn nhất tôi học được từ nó: Giữ định nghĩa menu tách biệt với việc thực hiện. Sử dụng định dạng tệp văn bản phân cấp (JSON / XML / ...) để mô tả menu, sau đó sử dụng ngôn ngữ kịch bản để chuyển đổi nó thành cấu trúc dữ liệu C hoặc C ++. Điều này cho phép bạn tự do thay đổi triển khai theo ý muốn và khả năng xử lý trước dữ liệu ở dạng hiệu quả nhất (giúp tránh phân bổ bộ nhớ động khi chạy).

— dùng694733

Đi với tùy chọn 1, tạo tĩnh một lớp cho mỗi mục UI để liên kết các sự kiện đầu vào với các hành động. Bằng cách này, việc thực hiện sẽ KHÔNG phân bổ bộ nhớ trong thời gian chạy.

Nếu trình biên dịch C ++ của bạn hỗ trợ đóng lambda, đó là một cách gọn gàng để liên kết các sự kiện đầu vào với các hành động trong mã thiết lập menu của bạn.

Với tất cả mọi thứ, các công cụ xác minh mã tĩnh có cơ hội nhận lỗi.

Bỏ qua các đề xuất để có "định dạng tệp menu" xây dựng các công cụ của riêng bạn. Bạn không kinh doanh bán các thư viện bộ công cụ menu, vì vậy đừng làm điều đó.

Bạn nói rằng bạn có một màn hình đồ họa nhỏ ... Đó có phải là đồ họa (hiển thị ánh xạ bit không?) Nếu bạn không sử dụng bộ công cụ GUI, hãy tự hỏi tại sao không? Nếu nó không phù hợp, đủ công bằng. QT nhúng hoặc một cái gì đó nhẹ hơn có thể giúp bạn tiết kiệm rất nhiều mã widget GUI dễ bị lỗi.

— Tim Williscroft
nguồn