2 つの質問:
- ここで何を達成しようとしていますか?
- コードをどの程度制御できますか? (つまり、何を変更できますか?)
意地悪をするつもりはありませんが、もう一度やり直したほうがいいかもしれません。このコードにはいくつかの問題があります。
まず、Singleton パターンは、特定のオブジェクトの 1 つだけが作成されることを保証する必要があるため、通常はポインター、参照、またはその派生物 (ブースト共有ポインターなど) によって返されます。ただし、必ずしも const である必要はありません。ここにあるのは、作成者がそれを const 以外の方法で使用することを意図していなかったことを示しています。
次に、このオブジェクトを参照によって関数に渡します。必要なし。これが、シングルトン パターンの主要な機能 (および欠点) の 1 つです。どこからでもアクセスできます。したがって、次のように簡単に書くことができます。
SomeClass::Construct()
{
IListener* pListener = const_cast<IListener*>(*Singleton::GetInstance());
}
これはまだ本当に役に立ちませんが。それが行うことの1つは、インターフェースを少し明確にすることです。SomeClass::Construct(const IListener&listener)
おわかりのように、誰かが書いたものを読んでいると、それが関数内でlistener
扱われることを合理的に暗示する可能性があり、 を使用することで、その暗黙の契約を破ったことになります。これは、少なくともこのような状況では使用すべきではないという非常に正当な理由です。const
const_cast
const_cast
自問する必要がある基本的な質問IListener
は、const の場合、なぜ const 内でそれを非 const の方法で使用する必要があるのかということですConstruct
。シングルトンが const オブジェクトを返さないか、関数が非 const である必要がないかのいずれかです。
これは設計上の問題であり、次の手順を実行する前に解決する必要があります。