問題タブ [decorator-chaining]

今、私は物事をよりスマートに行う方法を見つけようとしています. そうする過程で、私ができたのは、1日でフルボトルのエクセドリンを使用することだけです.

IRepository というインターフェイスがあるとします。

そして、私は次のような実装を持っていると仮定します

さて、すべて問題ありません。リポジトリに対してすべての基本操作を実行して、すべての CRUD 機能をサポートできますが、特殊な操作が必要な場合があるため、次のようなインターフェイスがあると仮定します。

そして、そのような実装：

オーケー、これで基本的なセットアップは完了です。次に、やりたいことがもう 1 つあります。ロギングやトランザクションなどをすべて透過的にしたいと考えています。そこで、Castle Windsor や StructureMap などの依存性注入フレームワークを使用して、IRepository を要求すると、LoggingRepository と TransactionRepository によってラップされるようにします。どちらも IRepository を実装しています。

だから、私がやりたいことは次のようなものです：

Logging および Transaction デコレーターにラップされたユーザー リポジトリを返すようにしますが、これが機能する方法が思い浮かびません。これを機能させると考えることができる唯一の方法は、次のように UserRepository を実装することです。

これは、依存性注入を使用して装飾されたリポジトリを作成し、それを UserRepository のコンストラクターに渡し、それを操作を実行するリポジトリとして使用することを意味します。これは機能しますが、まだ理想的ではないと思います。

したがって、私の質問は、これがこれを行う唯一の方法であるという点で正しいのでしょうか、それともこれを正しく理解していないのか、単に何かを見逃しているだけなのかということです。また、以前にこの問題に遭遇したことがある場合、この問題をどのように解決しましたか?

Javascript でデコレータ パターンを実装しています。

私はウィキペディアでここに例を見てきました

ここで私の質問は、パターンがまだデコレータ パターンであることです。親クラスが cost() 関数の最初または最後に呼び出されるかどうかは重要ですか?

確かに、これは各デコレータの動作に依存することを認識しています...たとえば、デコレータで加算または減算ではなく乗算または除算を行っている場合、もちろん異なる結果が保証されます。

しかし、前の段落で述べた理由以外に、前後に電話をかける理由はありますか?

django のファイルシステム キャッシュ デコレータを作成しています。問題は、関数をこのデコレータと @register.simple_tag で装飾すると、 my_decorated_func takes 0 arguments エラーが発生することです (ページがこのテンプレート タグで読み込まれた場合)

コンソールからパラメーターを指定して my_decorated_func を呼び出すことは問題ありませんが、テンプレートをレンダリングします:

エラーが発生します。

助言がありますか ？ありがとう ！

一部のデコレータは、最外層でのみ使用する必要があります。

元の関数を拡張し、configure パラメーターを追加するデコレーターはその一例です。

このようなデコレータが別のデコレータによって装飾されないようにするにはどうすればよいですか?

編集

新しいデコレータを適用しようとしているすべての人がアプリケーションの順序について心配するのは本当にうんざりです。

では、このような状況を回避することは可能でしょうか? 新しいパラメーターを導入せずに構成オプションを追加することは可能ですか?

ウィンザーにランダムな数のデコレーターで実装をラップするように強制しようとしているときに、次のことに遭遇しました。

私は3つのデコレータと実装をすべて同じインターフェースを使用しています。

このコードを実行すると、windsor は として解決icommandhandler<stringcommand>されますimplementation。これは、私が知る限り、予想される動作です。これは、型付き実装をオープン型付きデコレーターに登録できないためです。

ただし、行のコメントを外すと、container.Register(Component.For<ICommandHandler<stringCommand>>().ImplementedBy<Decorator1<stringCommand>>());3 つのデコレータすべてが を解決するために使用されますimplementation。これは望ましい結果です (: の並べ替え)。

なぜこれが起こっているのですか、これは私が気付いていないウィンザーの機能ですか? 同じ効果を達成するための別の方法はおそらくありますか？(リフレクションに頼ることなく)

私は一般的にパターンを設計することにあまり慣れておらず、Decorator を使用したことはありません。コンテキストに応じて異なる動作を持つオブジェクトが必要です。これらの動作は、異なるクラスで定義されています。Decorator がそのトリックを行うと思います。しかし、各デコレータが同じプロパティにアクセスでき、継承のように最初に子メソッドを呼び出せるようにする必要があります。だからここで私がやったこと：

これで、コンテキストに従って「継承」を「構築」できます。

動作を抽象化してオブジェクトを実行します。

それは私が望むことをしますが、:

• カプセル化はもうありません
• $this->親は醜い
• $this->これは醜い

あれについてどう思う？

• 別の方法でデコレータ(「子」)メソッドにアクセスするにはどうすればよいですか
• 継承されたコンテキストで保護されている場合のように、プロパティを共有するにはどうすればよいですか
• Decoratorの使い方が悪いのでしょうか？
• トリックを行うよりエレガントなパターンはありますか
• 親とこの属性は一種の車輪の再発明ですね。

現実世界の例: コーヒー マシン