1

わかりましたので、グローバル変数が悪いと見なされ、シングルトン パターンが乱用されていることはわかっています。また、クラスは 1 つのタスクだけを実行し、その 1 つのタスクを実行できるようにする変数のみを含める必要があることを多くの場所で読みました。しかし、最近のプロジェクトに取り組んでいる間、実際にコードを書く前にこれらのルールについて考え、プログラムの最初の段階でルールを破る傾向があることに気付きました。

私は現在、MFC ダイアログ ベースのアプリケーションに取り組んでいますが、この質問は UI 駆動型のアプリケーションに適用できます。ステート マシン、ファイルの読み取り/書き込み、およびハードウェア インターフェイスを処理する個別のクラスがあります。これらのオブジェクトはすべて、何らかのタイプの UI コントロールまたはプロパティの表示/編集が必要になります。MFC ダイアログ アプリケーションでは、ダイアログはプログラムなので、プログラムが閉じられるまで存在している必要があります。私は通常、オブジェクトをアプリケーションのメイン ダイアログ クラスに配置し、ダイアログ クラスに 2 つの役割を持たせました。アプリケーション内の他のすべてのオブジェクトのメイン UI とホームの両方として。他のアプリケーションでは、これらのオブジェクトをグローバルに作成し、必要な場所から参照しました。これらの方法はどちらも正しくないようです。最初のオプションは、1 つのクラス、1 つのタスク ルール、2 つ目はグローバルに依存し、隠れた依存関係も作成します。ある種の依存性注入を導入することはできますが、注入するこれらすべての変数はどこに存在するのでしょうか?

ルールを破ることなくプログラムを整理するために、他の人は何をしているのでしょうか?

4

3 に答える 3

2

シングルトンを MFC ダイアログ アプリケーションのメイン ダイアログ クラスのパブリック データ属性として格納することは、迅速で汚いプログラムでは問題なく機能することがわかりました。しかし、プログラムがより大きく複雑になるにつれて、物事が乱雑になり始めます。

ダイアログ クラスにシングルトンを格納することをリファクタリングする必要があるのは、おそらく、他のクラスがダイアログに含まれるシングルトンにアクセスできるように、ダイアログへのポインターを渡し始めるときです。

シングルトンはグローバル名前空間に移動できます。これは、特にそれらの数が多い場合は、まだ少し乱雑です。ヘッダーファイルにそれぞれのexternを個別に記述してから、それぞれをどこかに定義する必要があるため、すぐに昔ながらのCプログラムのように見えるものになります。

フレームワークがすでに定義しているシングルトンを利用するのは、すばらしいことです。これは、CWinApp の特殊化である、常に theApp と呼ばれるアプリケーション オブジェクトです。シングルトンをこれのパブリック データ メンバーとして配置すると、どのコードでも簡単にアクセスできます。

アプリケーションを「ソルバー」と呼んでいるとします。ダイアログ アプリケーション作成ウィザードは、クラス CsolverApp を作成します。ここで、「cData」クラスのインスタンスである「theData」というシングルトンがあるとします。

シングルトンを theApp に配置する

class CsolverApp : public CWinApp
{
public:

cData theData;

…

コードのどこからでもこれにアクセスするには

#include “solver.h”

theApp.theData.somepublicmethod();
于 2008-10-23T18:32:14.800 に答える
1

これを MVC (モデル - ビュー - コントローラー) の観点から見ることは理にかなっています。(MFC の命名が MVC へのオマージュであるというのは、Microsoft 側のもう 1 つの悪い冗談です。MFC 内で「真の」MVC に必要な抽象化のタイプを管理することは難しく、直感的ではありません (決して不可能ではありません)。)

具体的には、MVC 設計の基礎を考え出したようですね。基礎となるビジネス ロジックを実行するクラス (モデル) があり、UI コンポーネント (ビュー) から分離する必要があることがわかっています。今回の問題は、MVC 三位一体の 3 番目の部分です。コントローラー。

MFC は、明らかに意図的に MVC プロセスを難読化し、ダイアログから開始することで、このようなことを困難にしています。あなたのインスタンスでは、MFC が開始するダイアログは、ビューではなくコントローラーである必要があります。ダイアログ (コントローラ) が行っていることは、UI コンポーネント (ビュー) を管理し、それらが「作業」クラス (モデル) と対話できるようにすることです。これをさらに困難にしているのは、UI コンポーネントを表示するには、ほとんどの場合、ダイアログにアタッチする必要があることです。

この種のことを正しく行うには、基本的にコントローラーを、ダイアログからインスタンス化される高レベルのオブジェクトとして実装する必要があります。ダイアログは最初の制御フローが入る場所であり、コントローラーは制御フローを取得します。そこから、ダイアログを単なる別の UI コンポーネントとして扱う必要があります (特別なステータスを持つものではありますが)。

これにより、適切なレベルのカプセル化が可能になります。コントローラーは、必要に応じて相互に、またはコントローラーと通信できるビジネス ロジック (モデル) クラスを呼び出します。それらは、UI コンポーネントに埋め込まれ、(おそらく) UI 要素への過剰な特権アクセスの「簡単な方法」を取る代わりに、コントローラーによってビューから分離されます (「うーん、私はこのオブジェクトから何らかの入力を取得する必要があります。ユーザー; リファクタリングすることもできますが、最上位のウィンドウ ハンドルを持っているので、ダイアログ ボックスを表示する方がはるかに簡単です...")。

Controller オブジェクトがすべてのビジネス ロジック オブジェクトのホームになると、作業は簡単になります。コントローラーを使用して、他のオブジェクトを必要とするオブジェクトにクロスオブジェクト アクセスを提供できます。どのクラスをシングルトンにする必要があるかを考え、慎重に使用してください。競合管理を必要とするリソース (ハードウェア リソースなど) は、「自然なシングルトン」の好例です。シングルトンアプローチに役立つもの。コントローラーをシングルトンにすることもできます。それにアクセスするための要件に応じて。具体的には、依存関係の挿入シナリオでは、コントローラーは、オブジェクトをインスタンス化し、依存関係を管理する場所です。

これが基本的な MVC アプローチです。しかし、私が言ったように、MFC の基本的な設計のために、MFC は非常に難しく直感的ではありません。MFCによる最初の非常に否定的な印象の後、 MVC についてさらに多くのことを学びました。可能であれば、MVC の実装が他の言語でどのように見えるかを調べることをお勧めします。

幸運を！

于 2008-10-25T00:01:04.403 に答える
0

私の理解が正しければ、ダイアログ オブジェクトの有効期間が長すぎるように思えます。プログラムの期間中ダイアログを維持するのではなく、必要に応じてダイアログを作成および破棄することを検討する必要があります。

また、グローバル変数 (またはシングルトン) は、変数が表すものが、期間の短いオブジェクトの単なるプレースホルダーではなく、プログラムの存続期間中持続する真のグローバルなものである限り問題ありません。グローバルがメインダイアログに保存されていても、簡単にするために間違ったものにグローバルを使用すると、最終的にはあなたを悩ませます。

于 2008-10-20T21:41:41.300 に答える