4

私たちのチームの別の人が、彼の Web フレームワークの jar としてライブラリを提供してくれました。このフレームワークを「My Friend's Framework」と呼びましょう。

彼のフレームワークから必要な特定のクラスがあります。そのクラスによって公開されるプロパティの半分は、自分のアプリケーションに本当に必要なものです。残りの半分は必要ありません。このクラスのプロパティを取得するには、文字列操作を行う必要があります。このクラスの上に独自のフレームワークを開発するので、できるだけ依存関係を切り離したいと考えています。将来、私の別の友人がより良いフレームワークを開発するかもしれません。

そこで私がしたことは、そのクラスのファサード クラスを生成したことです。私自身のフレームワークは、ファサード クラスを介してプロパティにアクセスします。「My Friend's Framework」が変更された場合、1 つのファサード クラスを変更するだけで、残りは同じままです。さらに、文字列操作はファサード クラス内で行われます。また、ファサード クラスは必要なプロパティのみを公開します。したがって、私自身のフレームワークは、通常の getter/setter としてプロパティにアクセスするだけです。

しかし、私はこの男と口論をしました。彼は自分のクラスの実装を変更しないので、自分のクラスを直接使用するように強制しています。だから彼は、ファサードクラスを書くことは本当に価値がないと私に言いました。しかし、私は同意しません。

私が間違っている？私は自分が正しいと信じています。

4

3 に答える 3

11

原則として間違っていません。

あなたがしていることは見せかけではないという点であなたは間違っています。Facade は、多数のサービスを含む API がある場合に、より一般的に使用されます。これらのサービスをすべて一緒に使用することもできますが、それは複雑になる可能性があります。このパターンは、単一の API インターフェース (ファサード) を立ち上げ、サービス呼び出しを使用可能な論理アクションに調整します。

あなたがやっていることは、アダプターパターンに似ています。その前に別のクラスを配置することで、彼のクラスをユースケースに適合させています。

注意してください、私は単に意味論的な問題を指摘しているだけです.実際には、あなたがしていることは良い設計慣行です.

また、将来更新するつもりがない場合は、問題を解決する必要はないかもしれないことに注意してください。多分 YAGNI -- あなたはそれを必要としません。

于 2010-12-10T16:46:33.687 に答える
1

あなたのアプローチは私にはいいですね。

WHOLE フレームワークの実際の実装から非常に独立したインターフェイスを作成するようにしてください。単一のクラスを分離しようとしているという理由だけで、アダプターであると指摘している人もいますが、クラスが他のクラスと結合していると思われます。

質問に答えてみてください: このファサードはどのような秘密を隠す必要がありますか? 議論できるように、公開したいメソッドのいくつかを投稿してみてください。

于 2010-12-10T17:13:17.373 に答える
1

私には良いデザインのように聞こえます。

ファサードは通常、クラスのより大きなサブシステムへのインターフェイスを提供しますが、ファサードを使用して 1 つの複雑なクラスにアクセスできない理由がわかりません。

相手は頑固そうなので、枠から切り離すのがいいと思います。

あなたのファサードが使いやすい場合は、これを彼のフレームワークに追加して、他のすべての人にも提供できるようにすることができます。

于 2010-12-10T16:59:14.167 に答える