アダプタ実装から二つのタイプ、クラスおよびオブジェクトアダプタに分け、両方の差が（継承されたインタフェースと実装形態）の組み合わせを使用して連続を達成するためにさまざまな方法を採用することです。
A上のこれらの2つの異なるオブジェクトは、既存のコードを再利用することを除いて、使用目的から、2種類、およびデフォルトアダプタ特殊アダプタに分割することができ、現在のインターフェイスに適応デフォルトの実装を提供し、この方法は、サブクラスを達成するための必要性を回避するために実装すべきではありません。
まず、アダプタモードは、この設計モデルを忘れてください、システムの設計プロセスのように、あなたは無力ある場合には、モデルが唯一の救済、救済策であることを理解すべきです。
だから、ときに我々は、このモデルを使用していますか？シナリオはよくあるケースである、システムが完全なクラス構造を有しており、その我々は、関数（メソッドとも言える人気のポイント）の特定のタイプを使用する必要がありますが、私たちのクライアントは、別のものを認識し、クラスと構造的に無関係ですインタフェースアダプタモードこの時間は再生時間で、我々は我々の目標で、この既存のクラス・インターフェースを適応させることができ、最終的に、必要なインターフェイスを満たし、再利用可能なクラスであることを、機能のクラスが含まれています。
既存のクラスはオブザーバーインターフェイスを実装していないので、我々はクラスこれをすることができない場合次に、私たちは例を与える、我々は章オブザーバで述べたような問題は、それは、つまり、オブザーバーパターンの欠点であります観察者は本当にあまりにも悪いですオブザーバーのオブザーバーのリストに追加しました。
この問題では、我々は我々にはない、Observerクラスのインターフェイスを取得する必要がありますが、クラスの本来の機能を使用したいが、我々はこのクラスの元のコードを変更することはできません、またはクラスは、完全なクラスのシステムを持っていますそれを破壊したい、そして、あなたのアダプタモデルが最良の選択です。
我々は差観察者が、我々は全体MAPをクリアする必要があるとしたときに、これは、クラスがリストオブザーバに追加されたHashMapことを願っていますよう私たちは、具体的な例を与えます。しかし、今、なぜ、ああ行かない追加しますか？
オブザーバー観察可能な観察者のリストには、これだけのインターフェイスを認識しているので、それはそれを行う方法を、HashMapを認識しませんか？
この場合、私達は私達のアダプタクラスHashMapのは、手と足を行う使用することができ、すでに私たちは次のアダプタを書く方法をアダプタクラスを継承して使用する、と述べています。
パブリックHashMapObserverAdapterクラスは<Kは、V>のHashMap <K、V>実装オブザーバ延び{
公共ボイドアップデート（O観測物体のArgを）{
//観察者が変更、空のマップの場合
super.clearは（）;
}
}
それは、我々はクラスの機能を再利用したい、と私たちはオブザーバーである、それはアダプターが生成されますインタフェースアダプタを、実装する私たちの相続で、アダプタは元のクラス（つまり、HashMapの）機能を持っていますが、またオブザーバーを持っていますインターフェイスなので、アダプターは現在、オブザーバーのリストに追加することができます。
アダプタクラスは、右、非常に簡単です、見て？それでは、オブジェクトアダプタを見てみましょう、単にオブジェクトアダプタは、実装の使用を組み合わせたものであると述べました。
なぜそれを組み合わせて使用しますか？上記のアプローチは非常に良いではありませんか？
本質的には、その理由は、JAVA単一継承ので、JAVAクラスが一つだけの親クラスを持つことができますので、我々は、オブジェクトが時間の2クラスで適応したい場合、あなたはそれをどのように行うのですか？あなたは全体の2つのクラスを書いてみませんあなたの後ろに拡張し、あなたがしなければ、コンパイラはその不満を表明します。
我々は今、それはクラスの実体であると仮定すると、記述されたクラスを持っているなど、チャプター（アダプタモードを拭くために、古い多くの悲惨なオブザーバーパターン）用のObserverパターンの例を取ります。次のように。
パブリッククラスユーザーはBaseEntity {拡張
プライベート整数のIDを、
プライベート文字列名;
公共の整数のgetId（）{
IDを返します。
}
公共ボイドSETID（整数ID）{
this.id = ID。
}
パブリック文字列のgetName（）{
戻り名。
}
公共ボイドのsetName（文字列名）{
this.name =名。
}
}
参照してください、私たちのエンティティクラスのほとんどはBaseEntityから継承し、今あなたがそれを行うのですか、あなたはオブザーバ機能も観察可能なクラスを継承したい、あなたはそれを継承する方法を言います。
あなたは、私はユーザーBaseEntityが離れて得ることはありませ継承しない、話をするつもりはありません、私はBaseEntity内のすべてのものは、Userクラスに移動置く、または私が観察可能継承しませんし、観察可能な内部のすべてのものは、Userクラス内に移動しました。
これはノーではありませんが、これは、そのようなユーザーがBaseEntityを継承していなかった場合は、この時間は、あなたがこのクラスを逃します何かをする、BaseEntityのサブクラスをスキャンするために我々のプロジェクトへの時間として、大きなリスクです、それはあまりにも多くを支払ったあなたの継承システムを、破壊します。
あなたが観察継承しない場合は逆に、そして自分のUserクラスは非常に厄介に見える、と私は今だけUserクラスを観察することができると仮定し、私のPersonクラスは、従業員は、あなたが観測された観測可能なコーディングできるようにしたいですか、そこCOPY三回には3つのクラス？
今言ったことを忘れないでください、アダプタパターンは、私たちはコードを再利用するのに役立つ観察可能のコードや機能を再利用するために私たちを助けることができ、ここでアダプタモードを使用することです。
上記LZベースの議論、我々は次のアダプタ、オブジェクトアダプタを利用します。
//我们继承ユーザー、组合観察可能。
パブリッククラスObservableUserは、ユーザー{拡張
プライベート観察可能な観察可能な=新しい観察可能（）;
公共同期ボイドaddObserver（観察者O）{
observable.addObserver（O）
}
公共同期ボイドdeleteObserver（オブザーバーO）{
observable.deleteObserver（O）
}
公共ボイドnotifyObservers（）{
observable.notifyObservers（）。
}
公共ボイドnotifyObservers（オブジェクトのarg）{
observable.notifyObservers（引数）。
}
公共同期ボイドdeleteObservers（）{
observable.deleteObservers（）。
}
保護された同期ボイドsetChanged（）{
observable.setChanged（）。
}
ボイドclearChanged（）{同期保護
observable.clearChanged（）。
}
HASCHANGED公共同期ブール（）{
）（observable.hasChangedを返します。
}
パブリック同期int型countObservers（）{
）（observable.countObserversを返します。
}
}
私たちは、観察可能受け継ぐ私が言っているこのような理由のために、我々はプロジェクト内の継承階層を破壊することはできませんので、あなたがしたい場合は、当社のエンティティの継承階層における現在でも観測可能なユーザー（ObservableUser）は、別のObservableUserを持っているのではなく、ユーザーを継承します保護するために、ユーザのプロパティは、ユーザーのプロパティにする必要があります。
これは、私たちが観察を持っているユーザーだけで素晴らしいです。しかし、LZが、これは明らかに最善の解決策ではない、デザインパターンを利用するために、ずっと前に言いました。我々はまだ人、Employeeクラスが観測機能を持っている必要がある場合、これらの観察可能な方法以下、我々はまだそれを再度コピーする必要があるため、それは、実際には非常に悲惨ですので。
あなたはまだよりよい解決策を考える場合は、ここにヒントが、私は疑問に思いますか？特に初心者には、次を熟考することができます。
ここでは、基本クラスとして定義されている観測最終LZ比較的良好なソリューションです。
//我们扩展BaseEntity、适配出来一个可观察的实体基类
パブリッククラスBaseObservableEntityはBaseEntityを拡張{
プライベート観測観察=新しい観測（）。
公共同期ボイドaddObserver（観察者O）{
observable.addObserver（O）
}
公共同期ボイドdeleteObserver（オブザーバーO）{
observable.deleteObserver（O）
}
公共ボイドnotifyObservers（）{
observable.notifyObservers（）。
}
公共ボイドnotifyObservers（オブジェクトのarg）{
observable.notifyObservers（引数）。
}
公共同期ボイドdeleteObservers（）{
observable.deleteObservers（）。
}
保護された同期ボイドsetChanged（）{
observable.setChanged（）。
}
ボイドclearChanged（）{同期保護
observable.clearChanged（）。
}
HASCHANGED公共同期ブール（）{
）（observable.hasChangedを返します。
}
パブリック同期int型countObservers（）{
）（observable.countObserversを返します。
}
}
彼らを観察することができる機能を持っているしたい場合、これは単に素晴らしいです、そして今、我々はユーザーを持って、人は、従業員は、それはまだので、それらの3人に、十分BaseObservableEntityを継承するために私たちの適応を変更し、BaseObservableEntityのでBaseEntityを継承します私たちの継承システムの実体、そして我々はそれが本来の継承システムに損傷を与えないように、新しいBaseObservableEntityは、基本クラスを拡張しているため。
我々は既存のコードを再利用する以上の2つの方法があり、使用するアダプタパターン、アダプタのパターンは非常に明確で使用し、LZはちょうど別の目的に応じて、アダプタモードは、2つ、そして上記に分けることができ、言いました、呼び出すことができますされた最初のカスタムアダプタを、別のと呼ばれる存在であるデフォルトのアダプタ。
ほとんどの場合、改善することであるので、まず、我々はあなたがデフォルトのアダプタ、アダプタモードで表示したい理由を言わなければならない、救済策は今、その後、確かに我々は歴史的な理由にこのモデルを使用する必要があります。
のが理由デフォルトのアダプタの歴史を見てみましょう、私はあなたがまだ一般的な原則の最初の章を覚えていれば、LZは原則として、最小限のインターフェイスの原則を述べていたのだろうか。
この原則を表明アイデアは、インターフェイスの動作が続いLZが、その後、どのような状況でしょう、あなたがそれをしなかった場合は一度言ったことを覚えて少ないようであるべきと言っているのですか？
結果は、サブクラスである、このインタフェースを実装し、多くの方法の状況は結果が今、このサブクラスにアクセスすることはできませんが、あなたのインターフェイスのデザインが大きすぎるため、インタフェースの元のメソッドにつながることが表示されません、空の出現する可能性がありますこの方法が、Java言語の規則ので、インターフェースはそのすべてのメソッドを実装する必要がありますので、私たちはただコンパイルする、という点で、空のメソッドの束を書くことを余儀なくサブクラス実装しています。
したがって、この問題を解決するために、デフォルトのアダプタがありました。たとえば、我々は次のインタフェースを持っています。
パブリックインターフェイスの人{
無効話します（）;
ボイド）（聞きます。
空の仕事（）;
}
LZは、このインタフェースを実装するように、この人は、話す聞くと仕事ができ表すインターフェイスの一つであり、2年前にLZを想定し、それは家庭でも失業者である、LZは、ああああ仕事が、また、個人的なLZていませんでした、そうLZ、LZ人、LZが達成されなければならない人インタフェースをLZはその上の空の下にコピーする方法を働かせることができる、とLZが聴覚障害者であると仮定することは、よく、3つの方法が空であるために、しかし表明しました。
もちろん、上記は一例ですが、似たような状況になります実際のプロジェクトは、その後、どのようにそれを行うには？
次のようにこのダウン、我々は、アダプタにデフォルト設定します。
パブリッククラスDefaultPersonは人{実装し
ます。public void話す（）{
}
公共ボイド（）{聞き
}
公共ボイド仕事を（）{
}
}
私たちは、そこが空であるため、当然のことながら、何も、ここに書かないために、いくつかのデフォルトの方法であり、これはデフォルトの一部、実際の操作に加えてもよいという人のインターフェイスのデフォルト実装を作成しているような方法は非常に、整数の結果を返す場合など我々はゼロを返すことができ、デフォルトのアダプタをデフォルト。
これは単に素晴らしいです、限りLZは、デフォルトのアダプタ（DefaultPerson）を継承として、そのような話すように、ライン上のメソッドのLZの関心を上書きし、アダプタがデフォルトの実装を提供する私たちを助けるためにあるため、作業用として、耳を傾け、私たちはする必要はありません彼は書いています。
インターフェイスのデザインが唯一の理想的な状態であるため、このような状況は、実際に最小化し、多くの見つけ、いくつかの実装クラス、そのために特定のメソッドはメソッドが多すぎる場合、多くのサブカテゴリーとサブカテゴリーがありますが、この時点で興味を持っていませんがあるでしょう不可避でありますメソッドのほとんどが空である、それは、このように巻き取ることができます。
もちろん、そうすることはリヒターの置換原則に反しているが、アプローチの上にすでにインタフェースを最小限の原則に違反し、私たちは私たちが必要なものを最後に、実際の使用の両方の長所と短所を比較検討する必要があります。だから、このことから、私たちは、あくまでも目安として、原則的に、見ることができ、必ずしもすべてを満たすことができないではないので、我々は選択することを学ばなければなりません。
両方のシナリオでは、既存のコードのクラスを再利用するために、とのニーズが上がるクライアントにインタフェースするようになって両方、使用されるアダプタの実装をまとめています。
図1において、第1アダプター種は、一般に、目的はインタフェースを使用する場合に適合します。
2、第二の目的アダプタは、アダプタは、オブジェクトのターゲットはクラスであるか、再度ここでは、1回の使用よりも多くを多重化するために、時には一緒に複数のクラスを合わせるために特別なリマインダー、オブジェクトアダプタを必要とするため、一般的ですそれを組み合わせて使用していた、と私たちはオブジェクトアダプタを使用するときに、継承が必要とされていませんが、上記の例でなければならない実際のクラスとの関係に対処するために、直接的または間接的に、BaseEntityから継承されます当社オリジナルの継承システムを弱体化させないために、いくつかのケースでは、これは必要ありません。
3、第三デフォルトのアダプタは、通常、インターフェースが犯した過ちを補うためには大きすぎるが、長所と短所を比較検討ノートでは、良い後に重量を量るデフォルトのアダプタを使用するかどうかを検討してください。
さて、この目的のために、このアダプタモードのシェアは、私はあなたがポイントの収穫を得ることができることを望みます