Pertimbangan desain untuk menu konfigurasi pada sistem tertanam

Saya sedang mengerjakan sistem tertanam yang berinteraksi dengan pengguna dengan beberapa tombol dan tampilan grafik kecil.

Sebagai catatan: Karena saya menggunakan sistem tertanam, saya ingin mencegah alokasi memori dinamis sebanyak mungkin. Sesuatu seperti std :: vector bahkan tidak tersedia.

Saya perlu menerapkan menu konfigurasi menggunakan struktur menu bersarang klasik seperti ini:

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

Saya sangat tidak yakin tentang pendekatan terbaik di sini. Saya membaca tentang beberapa cara untuk mendekati sesuatu seperti ini seperti menggunakan Pola Komposit. Namun, saya selalu menabrak sesuatu yang tampak bagus "di atas kertas" tetapi tampaknya berantakan untuk diterapkan.

Pikiran umum saya adalah untuk memiliki sesuatu MenuNodekelas yang tahu tentang sub-node dan simpul orangtua pada inisialisasi. Sebuah Menukelas bisa menangani navigasi simpul dan pengolahan. Jelas, setiap orang MenuNodeharus menjalankan / menerapkan perilaku tertentu seperti:

Laporkan ke Menuapa yang ingin ditampilkan (tata letak / penentuan posisi yang sebenarnya tidak menjadi perhatian MenuNode)
Bereaksi terhadap input pengguna (seperti tombol, tekan untuk menambah / mengurangi / mengganti nilai)
Akses nilai aktual bunga (mereka berada di ApplicationSettingskelas)

Apa cara terbaik untuk mengimplementasikan ini?

Gunakan MenuNodekelas dasar (abstrak) dan buat sub-kelas untuk setiap item-simpul menu. Selama inisialisasi saya bisa memberikan pointer ke ApplicationSettingsatau dependensi lain yang mungkin diperlukan. Entah bagaimana rasanya membuat seperti 10 kelas turunan di mana masing-masing akan di-instal hanya sekali.
Gunakan MenuNodekelas yang sama untuk setiap node dan mengimplementasikan fungsionalitas melalui callback untuk membebaskan fungsi. Dari apa yang saya baca cukup umum untuk "pasangan" fungsi bebas dengan objek. Namun, rasanya akan terlalu menyulitkan. Untuk setiap anggota mungkin ada, seperti ReportButtonPress () atau sesuatu, saya harus memberikan panggilan balik untuk implementasi aktual selama inisialisasi.
Saya yakin ada sesuatu yang saya abaikan di sini.

— Rev1.0
sumber

Saya telah melakukan menu serupa untuk tertanam menggunakan C di masa lalu, dan ini adalah hal terbesar yang saya pelajari darinya: Jauhkan definisi menu terpisah dari implementasi. Gunakan format file teks hirarkis (JSON / XML / ...) untuk menggambarkan menu, lalu gunakan bahasa skrip untuk mengubahnya menjadi struktur data C atau C ++. Ini memberi Anda kebebasan untuk mengubah implementasi sesuka Anda, dan kemampuan untuk memproses ulang data ke bentuk yang paling efisien (membantu menghindari alokasi memori dinamis saat runtime).

— user694733

Pergi dengan opsi 1, buat secara statis satu kelas per item UI untuk mengikat peristiwa input ke tindakan. Dengan cara ini implementasinya TIDAK akan mengalokasikan memori pada saat runtime.

Jika kompiler C ++ Anda mendukung penutupan lambda, itu adalah cara yang rapi untuk mengikat peristiwa input ke tindakan dalam kode pengaturan menu Anda.

Dengan segala alat verifikasi kode statis memiliki peluang untuk mengambil kesalahan.

Abaikan saran untuk memiliki "format file menu" dan buat alat Anda sendiri. Anda tidak dalam bisnis menjual pustaka menu toolkit, jadi jangan lakukan itu.

Anda mengatakan bahwa Anda memiliki tampilan grafis kecil ... Apakah itu grafis (tampilan sedikit-dipetakan?) Jika Anda tidak menggunakan toolkit GUI, tanyakan pada diri sendiri mengapa tidak? Jika tidak cocok, cukup adil. QT tertanam atau sesuatu yang lebih ringan mungkin menghemat banyak kode widget GUI yang rentan kesalahan.

— Tim Williscroft
sumber