問題タブ [visitor-pattern]

Open/Closed Principleを尊重してVisitor パターンを実装することは可能ですが、新しい訪問可能なクラスを追加することはできますか?

オープン/クローズの原則では、「ソフトウェア エンティティ (クラス、モジュール、関数など) は、拡張に対してオープンである必要がありますが、変更に対してクローズされている必要があります」と述べています。

AbstractVisitor から派生する任意の数のクラスを実装できます。これは拡張可能です。AbstractVisitor から派生したクラスはコンパイルされないため、新しい訪問可能なクラスを追加することはできません。変更のために閉じられました。

AbstractVisitor クラス ツリーは、Open/Closed Principle を尊重します。AbstractVisitable クラス ツリーは、拡張できないため、Open/Closed Principle を尊重しません。

以下のように AbstractVisitor と AbstractVisitable を拡張する以外の解決策はありますか?

ビジターデザインパターンをコードに適用することと、次のアプローチとの違いは何ですか。

インターフェイスを使用することで、アルゴリズムを実際に分離しているわけではないと思います。

私は自分のアプリの 1 つにコア アーキテクチャのアイデアの 1 つとして訪問者を導入しました。同じものを操作する訪問者が何人かいます。さて、どのようにテストすればよいでしょうか？私が考えているいくつかのテストは、単体テスト（統合テストなど）よりも少し大きいですが、それでもやりたいと思っています。訪問者パターンの wiki アートの C++ サンプルのようなコードをどのようにテストしますか?

ブログで訪問者パターンへの言及をよく見かけますが、認めざるを得ません。パターンのウィキペディアの記事を読み、その仕組みを理解しましたが、いつ使用するかについてはまだ混乱しています。

最近本当にデコレータ パターンを手に入れた人として、この一見便利なパターンを直感的に理解できるようになりたいと思っています。

Visitor パターンを使用しようとしていますが、次のようにしています。

訪問者 ：

そして、私が訪問者を呼んでいるところ：

だから..私はどこで参照を失っていますか? newItem = foundTag の後 - 訪問者の foreach で新しい値が得られることを期待しています - 明らかにそれは起こっていません。

編集私は答えを見つけたと思います-foreachでは変数は読み取り専用です。

http://discuss.joelonsoftware.com/default.asp?dotnet.12.521767.19

C＃3.0拡張メソッドは、基本Typeに拡張機能を追加し、そのTypeのすべてのインスタンスでそのメソッドを呼び出すことを有効にします。

今、私が知っているJavaScriptは、特定のインスタンスにメソッドを追加できるIDispatchExを実装しています。

では、C＃クラスの「インスタンス」に一連のメソッドを追加するにはどうすればよいですか？私はこれが動的言語と静的言語の聖戦の領土であることを知っています。:)私の意図はそれではないことを明確にさせてください。

インターフェイスを実装するクラスに応じて、一連のイベントをインターフェイスに追加できるようにしたいだけです。

Genericsを使用してそれを行うことができました

それで私はSupportedEvents言いたくなかった

それから私はJavaScript（私C#はそうではないことを知っていJSます:)）... AND、、IDispatchExなどなどを考えIL Weaving、Reflection.Emitこれを行う方法があるかもしれないと思いました... [設計時のサポートは素晴らしいですが、私はなくても生きることができます]

はい、おそらくビジターパターンでこの「インスタンス拡張」を行うことができます。[糖衣構文を入手できるかどうかはわかりませんが]

コメント？

クラスの階層があるとします。古典的な例を使用しましょうShape。

abstract class Shape
Circle : Shape
Square : Shape

さまざまな方法で形状のレンダリングを処理するレンダラー クラスの 2 番目の階層があります。

abstract class ShapeRenderer
HtmlShapeRenderer : ShapeRenderer
WindowsFormsShapeRenderer : ShapeRenderer

これらを個別に変更できるようにするには、従来、ブリッジ パターンを使用する必要がありました。クラスを変更せずにレンダリング アクションを拡張できるようにするには、Shape従来、Visitor パターンが必要でした。

ただし、これらは両方とも、抽象化側ではなく、実装側の拡張のみに焦点を当てています。新しい を追加したいとします。Shapeたとえば、TriangleのレンダリングもサポートできるようにしたいとしTriangleます。Visitor パターンと Bridge パターンの両方が、抽象化階層を一連のメソッドに「フラット化」することに依存しているため、次のようになります。

階層を拡張する唯一の方法Shapeは、基本クラスのコードを変更するShapeRendererことです。これは重大な変更です。

ジョン、明確にするために：ブリッジまたはビジターを使用すると、クライアントは代替のレンダリング実装を提供できますが、潜在的なすべてのシェイプについて知る必要があります。私ができるようにしたいのは、クライアントがクラスを拡張できるようにし、新しいクラスのレンダリング実装を提供するようにクライアントに要求することです。このように、既存のコードは、レンダリングの詳細を気にすることなく、あらゆるタイプの で動作します。ShapeShape

C# で使用できるこの種の問題に対する一般的な解決策はありますか?

複製：ビジターデザインパターンをいつ使用する必要があるか

なぜ誰かがビジターパターンを使いたいのでしょうか？いくつかの記事を読みましたが、何も得られません。

カスタムを請求する機能が必要な場合は、

またはのようなもの

2つ目はそれほど複雑ではなく、Bill関数はCustomerクラスから分離されています。では、なぜビジターパターンを使用したいのでしょうか。

私は、Javaプログラムの短絡制御フロー構造として、チェックされていない例外を使用するように強く誘惑されています。ここの誰かがこの問題を処理するためのより良い、よりクリーンな方法について私にアドバイスしてくれることを願っています。

アイデアは、すべてのメソッド呼び出しで「停止」フラグをチェックすることなく、訪問者によるサブツリーの再帰的な探索を短縮したいということです。具体的には、抽象構文ツリーの訪問者を使用して制御フローグラフを作成しています。ASTのreturnステートメントは、サブツリーの探索を停止し、訪問者を最も近い囲んでいるif/thenまたはループブロックに戻す必要があります。

（ XTCライブラリからの）Visitorスーパークラスは次のように定義します

フォームのリフレクションメソッドを介してコールバックします

dispatch例外をスローするように宣言されていないので、拡張するプライベートクラスを宣言しましたRuntimeException

これで、returnステートメントのvisitorメソッドは次のようになります。

そして、すべての複合ステートメントは、ReturnException

これはすべて正常に機能しますが、次の場合を除きます。

1. 私はどこかで捕まえるのを忘れるかもしれReturnExceptionません、そしてコンパイラは私に警告しません。
2. 汚れた感じがします。

これを行うためのより良い方法はありますか？この種の非ローカル制御フローを実装するために私が気付いていないJavaパターンはありますか？

[更新]この特定の例はやや無効であることが判明しました。Visitorスーパークラスは例外（sでも）をキャッチしてラップRuntimeExceptionするため、例外のスローは実際には役に立ちません。enumから型を返すという提案を実装しましたvisitReturnStatement。幸いなことに、これは少数の場所（たとえばvisitCompoundStatement）でチェックする必要があるだけなので、実際には例外をスローするよりも少し面倒ではありません。

一般的に、これはまだ有効な質問だと思います。おそらく、サードパーティのライブラリに縛られていない場合は、賢明な設計で問題全体を回避できます。

Web デザイナーが構成する必要があるかなり複雑なフォームがいくつかあります。

仕事をしているように見えるいくつかの複合コントロールを構築してきました。

最上位のコントロールは単なるコンテナーであり、フォームのセクションはその中に含まれています。SubControls は共通のインターフェイスを実装します (つまり、NeptuneAddressControl と MarsAddressControl は IPlanetaryAddressControl を実装します)。

最終的には、すべてを同じデータベースに入れる必要があります。

子コントロールのすべてのフィールドを親の props として公開する代わりに、コントロール ツリーにまたがる Visitor を実装し、データベースに書き込むことができる Entity Object を設定することを考えています。

これは正しいアプローチですか、それとも私はここから離れていますか?