問題タブ [proxy-pattern]

以下を可能にするFooオブジェクトがあるとします。

これには、プロキシの設計パターンが必要です ( Scott Meyers による詳細はこちら) 。

しかしここで、everymyFoo[i]もFooインスタンスであるとしましょう。

私は実装に近づいていますが、最後の厄介な「前方宣言/不完全型」エラーを取り除くことはできません。

まず、簡単なものから始めましょう。

基本的な非再帰プロキシ パターンは次のとおりです。

その最後のハンドラーが必要かどうかわかりません。

とにかく、再帰的にするには、次のものが必要です。

Proxyこれは、内で定義できなくなったことを意味しますObject。そうしないと、「不完全な型をベースにしようとしています」というコンパイラ エラーが発生します。

では、そうしましょう。また、可能な場合はコンストラクターを変更して基本クラスを埋める必要があります。

そして、Object基本クラスにより、typecast-to-object を手動で処理する必要がなくなります。

しかし、これはそれが危険になるところです。

Object::Proxyの定義を (実際には後) の外に移動するObjectと、元の

... 不完全なクラス ( Proxy) を使用しているため、エラーが発生します。単に定義を外側に移動しても、戻り値の型が であるという事実は修正されないことに注意してくださいProxy。それができればProxy*。しかし、Proxyできません。

これは Catch-22 のように見えますが、明確な解決策は見当たりません。

ありますか？

編集: 欠陥のある設計を示唆するコメントに応じてObject、ポインターの軽量ラッパーであることに注意してください。PyObject*データ メンバーは 1 つだけです。

編集:私が取り組んでいる元のコードはここにあります

PyObject*PythonをObjectクラスにラップしようとしています。Python では、すべてがPyObject*. リストは でありPyObject*、リスト内の各項目自体がPyObject*です。これは別のリストになる可能性さえあります。等

fooList[42] = barObjProxy パターン ( here ) を使用してスタイル構文を許可しようとしています。

fooList[42]これで機能するようになったので、拡張してとして使用できるようにしたいと思いObjectます。具体的には対応できるようになりたい...

Objectには多くのメソッドがあり、現在、最初に をインスタンスにfooList[42].myObjMethod()解決fooList[42]し、次に を試みます。ProxytmpProxytmpProxy.myObjMethod()

これは、私がしなければならないことを意味します

Objectつまり、の各メソッドを を介して手動でリレーしますがProxy、これは見苦しいものです。

完璧な解決策はありませんが（上記のリンクされた回答を参照）、喜んで使用します：

... 妥協案として、-> をオーバーロードできる(オーバーロードできないのとは対照的に)と見なし.ます。

ただし、オーバーロードに関するドキュメントが見つかりませんoperator->。

私の最善の推測は、何らかのオブジェクトへのポインターを返す必要があり (たとえばpObj)、C++ が を呼び出すことpObj->whateverです。

以下は私の試みた実装です。ただし、「オブジェクト型の一時オブジェクトのアドレスを取得しています」という警告が表示されます。

私はObjectクラス内に持っています：

「const Object&」は、「オブジェクト型の一時オブジェクトのアドレスを取得する」という警告に遭遇することに注意してください。

アイデアは、myList[5]->someMemberObj = ...スタイル構文を許可することです。

myList[5]( の 6 番目の要素)Proxyをラップするインスタンスとして解決されます。と呼びましょう。ObjectmyListmyItem

今、私は、またはsomeProxy->fooFunc()それぞれsomeProxy->fooPropertyを呼び出したいです。myItem.fooFunc()myItem.fooProperty

「オブジェクト型の一時オブジェクトのアドレスを取得しています」という警告が表示されます。

サードパーティのライブラリ クラスに依存するサービスを実装する良い方法を見つけようとしています。また、ライブラリが利用できない場合や回答を提供できない場合に備えて、フォールバックとして使用する「デフォルト」の実装もあります。

サービスの実際の実装は次のようになります。

現在の実装は、サービスへの実際の呼び出しのみが異なるという点で少し重複しているように見えますが、try/catch とデフォルトのメカニズムはほとんど同じです。また、サービスに別のメソッドが追加された場合、実装はほとんど同じになります。

コードの見栄えを良くし、追加のコピーと貼り付けを少なくするために、ここ ( proxy、strategy ) に適用できる設計パターンはありますか?

以下のクラス ダイアグラムでは、プラグイン/拡張システムの現在のアプローチを確認できます。拡張機能に、一般的/グローバルな API を提供したいと考えています。ただし、公開される API は、参照されるオブジェクトの実際の機能のサブセットのみで構成される必要があります。私の最初の考えは、インターフェイスを使用することでした。これに関する問題は、悪質なプラグインがインターフェースを内部クラスにダウンキャストして混乱させる可能性があることです。(私も気にする必要がありますか?) 2 番目の考えは、プロキシ パターンを使用することでした。現在、私はそれらの両方を使用しています。これは本当に必要ではないと思います。しかし、バイナリ互換性を念頭に置いて、ここで複雑さを軽減するにはどうすればよいでしょうか?

NSObject から継承されたカスタム オブジェクトの構成オブジェクトを作成するために、Swift でプロキシ パターンを実装しようとしています。UIView の UIAppearance のようなものになります。forwardInvocation:しかし、メソッドとNSInvocationクラスを使用して object -c で行うメソッド呼び出し転送の方法がわかりません。

誰かがそのような問題に直面し、解決策を持っているなら、私は聞いて感謝します. 前もって感謝します。