組み込みシステムの構成メニューの設計上の考慮事項

私は、いくつかのボタンと小さなグラフィックディスプレイでユーザーとインターフェイスする組み込みシステムに取り組んでいます。

余談ですが、私は組み込みシステムを使用しているので、動的なメモリ割り当てをできるだけ回避したいと思います。std :: vectorのようなものは利用できません。

次のように、クラシックなネストされたメニュー構造を使用して構成メニューを実装する必要があります。

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

ここでの最善のアプローチについてはよくわかりません。複合パターンを使用するなど、このようなものにアプローチするいくつかの方法について読みました。しかし、私はいつも「紙の上」では良さそうに見えても、実装するのは面倒そうなものにぶつかります。

私の一般的な考えはMenuNode、初期化時にそのサブノードと親ノードについて知っているクラスを持つことです。Menuクラスは、ノードナビゲーションおよび処理を扱うことができます。明らかに、すべてMenuNodeが次のような特定の動作を実行/実装する必要があります。

• Menu何を表示したいかを報告します（実際のレイアウト/配置はの問題ではありませんMenuNode）。
• ユーザー入力に反応する（値を増減する/ボタンを押すなど）
• 関心のある実際の値にアクセスする（ApplicationSettingsクラスに属している）

これを実装する最良の方法は何でしょうか？

1. （抽象的な）MenuNode基本クラスを使用して、すべてのメニューノード項目のサブクラスを作成します。初期化中に、ApplicationSettings必要になる可能性のある他の依存関係へのポインタを提供できます。どういうわけか、それぞれが一度だけインスタンス化される10個の派生クラスを作成するのは間違っていると感じています。

2. MenuNodeすべてのノードに同じクラスを使用し、関数を解放するコールバックを通じて機能を実装します。私が読んだことから、そのかなり一般的なものは、自由な関数をオブジェクトと「結合」することです。しかし、それは物事を複雑にしてしまうような気がします。ReportButtonPress（）などのメンバーごとに、初期化中に実際の実装のコールバックを提供する必要があります。

3. ここで見落としているものがあると思います。

オプション1で、UIイベントごとに1つのクラスを静的に作成し、入力イベントをアクションにバインドします。この方法では、実装は実行時にメモリを割り当てません。

C ++コンパイラがラムダクロージャをサポートしている場合、それは入力イベントをメニューセットアップコードのアクションにバインドする整然とした方法です。

すべての静的コード検証ツールを使用すると、エラーが発生する可能性があります。

「メニューファイル形式」で独自のツールを構築するという提案は無視してください。メニューツールキットライブラリを販売しているわけではないので、販売しないでください。

あなたは小さなグラフィックディスプレイを持っていると言います...それはグラフィック（ビットマップディスプレイですか？）収まらない場合は、十分に公正です。QTが組み込まれていたり、軽いものを使用したりすると、エラーが発生しやすいGUIウィジェットコードを大幅に節約できます。