多数のコンポーネントで使用される「グローバル」構成クラスを作成するためのベストプラクティス


11

ドライバーパーツと、さまざまな関連タスクを実行する約5つのライブラリーを持つ大規模なプロジェクトがあります。ライブラリの多くは、起動時にドライバーコードによってデータベースから読み取られる「グローバル」構成データへのアクセスを必要とします。ドライバーとは、メイン機能を含む部分を意味します。

これを処理する方法についての私の考えは、構成項目を取得する静的メソッドを使用して構成クラスを作成することでした。これは最善の方法ですか?他にどのようにこれを達成できますか?

例えば:

class config {
 public:
   static get_item(key);

 private:
   static values;
};

シングルトン設計はここで適切ですか?

回答:


14

シングルトン以外の方法は、通常のプロパティ/メンバーで通常の構成クラスを作成し、そのオブジェクトをデータベースのドライバーの正しい設定でインスタンス化し、インスタンスをすべてのライブラリーに(おそらくstd :: shared_ptrを介して)渡すことです。これは、依存性注入と呼ばれる一般的な設計パターンです。

そうすることで、シングルトンデザインパターンの潜在的な問題をすべて回避できます。また、構成クラスのインスタンスを任意の方法で任意のデータでインスタンス化してテストできるため、コードをよりテストしやすくなります。


+1、テスト可能性についてそのことを自分の答えに追加したかったのですが、あなたはより迅速でした。
Doc Brown

少しOT:それはまだシングルトンではないですか?
adhominem 2013年

1
@adhominem-いいえ、それはたまたま単一のインスタンスしか存在しないオブジェクトですが、その周りに特別な機構はありません。
Joris Timmermans、2013年

@OliverWeiler-正解です。私は実際にそのデザインパターン名を回答で参照する必要があったので、ここで追加します。
Joris Timmermans

1

これは、シングルトンが実際に行うべき正しいことの1つだと思います。

クラス自体のインターフェースに関しては、get-by-key-nameを実行するか、個々の構成値のアクセサーを使用できます。後者のスキームは、いくつかの便利さ(IDE補完機能)を提供し、使用する前に構成値を正しいデータ型にキャストできます。また、configクラスのユーザーとその内部実装の間にいくつかの分離が導入されています(すべてのconfig値が文字列として格納されるという事実は、クラスのユーザーが気にする必要のない実装の詳細です)。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.