プログラミングデザインパターン：ファサードかどうか

Question

私たちのチームのもう一人の人が、自分のWebフレームワークのためのライブラリとして私にライブラリを提供しました。このフレームワークを「My Friend's Framework」と呼ぶことにしましょう。

私は彼のフレームワークから必要なクラスがあります。そのクラスで公開されているプロパティの半分は、自分のアプリケーションに本当に必要なものです。もう半分は必要ありません。このクラスのプロパティを取得するには、いくつかのString操作を行う必要があります。このクラスの上に私自身のフレームワークを開発しているので、可能な限り依存関係を切り離したいと思っています。多分将来、私の別の友人がより良いフレームワークを開発するでしょう。

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

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

私は間違っていますか？私は正しいと信じています。

Answer 1

あなたは原則として間違っていません。

あなたがしていることがファサードではないということが間違っています。ファサードは、サービスがたくさんあるAPIを使用している場合に、より一般的に使用されます。これらのサービスを一緒に使うことはできますが、それは複雑になる可能性があります。このパターンは、サービス呼び出しを使用可能な論理アクションに調整するファサードである単一のAPIインターフェイスを立てることです。

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

私は単に意味論的な問題を指摘していることに注意してください。実際には、あなたがやっていることは良いデザインの実践です。

また、今後更新を予定していない場合は、問題を解決する必要はありません。たぶんYAGNI - あなたはそれを必要としないでしょう。

Answer 2

私には良いデザインのようなサウンドです。

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

他の人が頑固なように聞こえるので、彼のフレームワークから切り離すと良いと思います。

あなたのファサードが使いやすくなっていれば、彼のフレームワークにこの機能を追加して他の人にも提供することができます。

Answer 3

あなたのアプローチはよかったです。

WHOLEフレームワークの実際の実装とはまったく独立したインターフェイスを作成してください。他の人は、あなたが1つのクラスを切り離そうとしているという理由だけで、それがアダプタであると指摘しましたが、クラスが他のクラスと結合していると思われます。

質問に答えるようにしてください。この正面はどのような秘密に隠れていますか？ 私たちが議論できるように公開したいメソッドのいくつかを投稿しようとしてください。