8

私はプログラミングを独学しようとしている最中です。私は、ほとんどの人が始めると確信しているのと同じ方法で始めました。単純なことをそれほど単純ではない方法で行う、小さくて厄介なアプリやゲームを作成します。最近、OOP 設計を使用して、より優れた、よりモジュール化されたコードを作成する、もう少し複雑なゲームを作成することで、次のステップに進もうとしています。

私が抱えている主な問題は、メインの StateManager (FSM) クラスの設計です (イントロ/メニュー/ゲーム/その他の画面状態を切り替えるため)。私は高低を見てきましたが、それらを設計する2つの方法しか実際に見たことはありません:

  • 状態を切り替えるには、switch/case ステートメント + 列挙型を使用します。

  • ベクトルへの/からの状態のプッシュ/ポッピングを処理するシングルトン FSM クラスを作成します。

さて、私の問題は、switch case ステートメントが非常に反復的でぎこちなく、このプロジェクトを使用して OOP を独学するという私の目標に反することです。

私の2番目の大きな問題は、「シングルトン」の提案です。

前に言ったように、私は自分自身を学ぼうとしていますが、プログラミングに関しては、特に OOP やデザイン パターンなどの分野で、まだ学ぶべきことがたくさんあります。私が見つけたすべての単一の「シングルトンは悪」のスレッドと議論について、人々がコードでシングルトンを使用して「エンジン」クラスとFSMを作成するチュートリアルと参照を見つけるという問題に遭遇しました。それは非常に一貫した混合メッセージです。

理由がわからないだけだと思います...クラスの単一のオブジェクトのみを持ちたい/意図している場合でも、コンストラクターをプライベートにしてシングルトンを作成することが必要/有益なのはなぜですか? シングルトンがいかに悪いか、それらが本質的にグローバルである方法、マルチスレッドの邪魔になる方法、そしてどれだけ多くのプログラマーがそれらを使いすぎているか、単に悪い設計であると考えているかについて多くのことを読んできました...それでも私は例の後に例を見ますそれらを使用している人々の数、および代替方法を示す反例はほとんどありません。

通常のクラスだけで同じようなことができないのでしょうか？インスタンスの作成を明示的に制限する目的は何ですか? シングルトンについて否定的なことしか聞いたことがありませんが、人々は常にそれらを使用しているようです...シングルトンとOOPについて完全に何かが欠けていますか?

シングルトンの使用は単なるトレンドですか、それとも人々がシングルトンを「悪」と呼ぶときのトレンドですか? どうすればこれを回避できますか..? スイッチ/ケース FSM とシングルトン FSM の間に何かありませんか?? クラスのシングルトンを作成せずに、プログラムの状態システムをまったく同じ方法で設計できませんでしたか? それは何かを変えるでしょうか？[混乱]

4

3 に答える 3

6

通常のクラスだけで同じようなことができないのでしょうか？インスタンスの作成を明示的に制限する目的は何ですか? シングルトンについて否定的なことしか聞いたことがありませんが、人々は常にそれらを使用しているようです...シングルトンとOOPについて完全に何かが欠けていますか?

いいえ、あなたは正しい道を進んでいると思います。2 つのインスタンスの作成を禁止する理由はまったくありません。そのため、宇宙は内破しません。

まったく不要な制限です。その制限を手動でコーディングする必要があるため、それを行うのはまったくばかげています (それを解除するためにコードを書かなければならない場合、それは別の問題になります)。

2 番目のインスタンスが作成された場合にユニバースが内破するという奇妙でまれな状況があると思いますが、それはかなり大げさに聞こえます。いずれにせよ、インターネット全体にシングルトンが蔓延していることは正当化できません。

なぜ人々が常にそれらを使用しているのかを、その人々の推論能力を侮辱することなく説明することはできませんので、私はそうするのを控えます.

クラスのシングルトンを作成せずに、プログラムの状態システムをまったく同じ方法で設計できない人がいるでしょうか? それは何かを変えるでしょうか？

唯一の変更点は、シングルトンにすることで、単体テスト用の使い捨てインスタンスを作成することを防ぐことです。他のすべては同じように機能します。

于 2012-08-09T11:19:51.057 に答える
3

よくあることですが、簡単な答えはありません。C ++では、シングルトンパターンは初期化の問題の順序も管理します。これは、静的オブジェクトのコンストラクターで使用する場合に重要です。また、複数のインスタンスがプログラミングエラーにすぎない特定の種類のオブジェクトがあります。あなたがそれらを防ぐことができるなら、なぜそうしないのですか。

一方、StateManagerクラスがシングルトンである必要がある場合を想像するのは非常に困難です。独自のリソースや、本質的に固有でなければならないメタ機能（ロギングなど）を管理することは決してありません。また、静的オブジェクトのコンストラクターでも使用されているとは想像できません。

「シングルトンは悪い」などの記述は非常に誤解を招く可能性があります。いくつかの点で、それらは最も適切な解決策です。しかし、絶対的に悪くないからといって、どこでも適切であるとは限りません。それらは1つの特定の非常に限られた問題を解決します。その問題を解決する必要がある場合、シングルトンを使用しないのは悪いことです。しかし（ほぼすべてに当てはまるように）、適切でないときにそれを使用することは悪いことです。

于 2012-08-09T12:09:30.693 に答える
1

FSMクラスがシングルトンである理由がわかりません。シングルトンがない実際のFSMシステムはたくさんありますが、SMが状態をトラバースするときに状態インスタンスが作成および破棄されるものや、ステートマシン自体が階層の簡単な構成を可能にする状態であるものもあります。ステートマシン。

複雑なアプリケーションでは、複数のステートマシンがあり、そのうちのいくつかは存在したり存在しなくなったりします。たとえば、クライアントとサーバーの相互作用を処理するものには、必然的に、クライアントと出入りする複数のインスタンスがあります。他のいくつかは、複数の階層ステートマシンを構成することで恩恵を受ける可能性があり、そのいくつかは多くの場所で再利用される可能性があります。したがって、シングルトンクラスとしてステートマシンを使用するという考えは私にはばかげています。たとえば、アプリケーションをカプセル化するシングルトンアプリケーションクラスに特定のステートマシンのインスタンスがある場合がありますが、それはシングルトンクラスのステートマシンを持つにはほど遠いです。

フラットFSMと階層ステートマシン（HSM）の対比など、さまざまなステートマシンの実装手法の概要を理解するには、MiroSamekのPSICC2の本を参照してください。彼は、一般的なテクニックが説明されている無料でダウンロードできる記事をたくさん持っています。

UIに使用できる階層型ステートマシンの合理的なC++実装は、Qtのステートマシンフレームワークで利用できます。

于 2012-08-09T11:50:55.490 に答える