JAVAの依存関係逆転原理
アメリカ法の最も基本的な原則の 1 つは「すべての人は平等である」ですが、それがどのような闘争や流血を経て達成されたかは気にせず、次のように定義されています。
publicfinal boolean 全員が平等(person 1, person 2){
true を返します。
}
アメリカ合衆国基本法のように各州の法律は異なりますが、ニューヨーク州はニューヨーク基本法と呼ばれる場合があります。つまり、ニューヨーク基本法はアメリカ合衆国基本法を継承するという関係にあるはずです。と述べていますが、このメソッドの書き換えは許可されていません。
ニューヨーク州での執行に関しては、次のものが使用されます。
アメリカ合衆国基本法 = 新しいニューヨーク基本法
どこでも「全員平等」メソッドを呼び出すと「true」が返されます。これは、全員の平等の原則はどこでも変更できないことを意味します。これはミクロを決定するマクロの決定であり、New により男性と女性の間で変更されません。ヨークの女性の不平等。
例えば、ある国にも基本法があり、万人平等の方法があります。定義は次のようになります。
public boolean 誰もが平等です(人 1, 人 2){
true を返します。
}
例えば、ある国のある場所にも基本法はありますが、その国の基本法も受け継がれていますが、「みんな平等」というやり方は最終的なものではありません。特定の場所に実装されると、次のように書き換えられる可能性があります。
某国の基本法＝某所の新基本法
または
ある場所の基本法＝ある場所の新しい基本法
おそらく、どこかの基本法がどこかの国の基本法を引き継いだ際に、「みんな平等」というやり方が書き換えられ、次のように変更されたのでしょう。
public boolean 誰もが平等です(人 1, 人 2){
if(人 1== ある場所の人&& 人 2== ある場所の人){
if(人物 1 と人物 2 は同じ属性を持っています){
if(人物 1 と人物 2 は、同じ人物ではないことを除いて同じです){
if(他に何も起こらない){
true を返します。
}それ以外{
false を返します。
}
}それ以外{
false を返します。
}
}それ以外{
false を返します。
}
}それ以外{
false を返します。
}
}
「JAVA とパターン」に従って、依存関係逆転の原則について話しましょう。
抽象レベルには、アプリケーション システムのビジネス ロジックと、システム全体にとって重要で必然性を反映するマクロレベルの戦略的決定が含まれますが、具体レベルには、いくつかのマイナーな実装関連のアルゴリズムとロジック、および戦術が含まれます。決定にはかなりのチャンスが伴います。コードの特定のレベルは頻繁に変更されるため、エラーを避けることはできません。抽象化のレベルは具体性のレベルに依存し、特定レベルの詳細を使用したアルゴリズムの変更は、抽象化レベルの巨視的なビジネス ロジックに即座に影響を与え、ミクロが巨視を決定し、戦術が戦略を決定し、必要性が偶然に決定されます。これはとんでもないことだ。
これを読むと、今後コードを記述する際に、なぜこれをより頻繁に使用する必要があるのかが理解できるでしょう。
抽象論理 = 新しい具体論理
使用量は最小限に抑えます。
特定のロジック = 新しい特定のロジック
これが現在提唱されているインターフェース指向プログラミングです。インターフェース指向プログラミングのもう 1 つの実践例を次に示します。
通常は List を使用することをお勧めします。List 自体は Collection から継承されたインターフェイスです。次のように使用できます。
リスト list=new Vector();
この方法で宣言された List は実際には Vector 型です。Vector はそのサブクラスであるため、Liskov 置換原則によれば、親クラスが受け入れられる場所であればどこでもサブクラスを受け入れることができます。このとき、リストは同期されますが、当然、パフォーマンスによっては影響を受けます。将来的に同期を必要としない環境に変更する場合は、上記のコードを次のように変更するだけで済みます。
リスト list=new ArrayList();
現時点では、他のコードを変更する必要はありません。List の実際のタイプは ArrayList です。
この点から、インターフェイス指向プログラミングが設計者によって重視される理由がわかります。設計者がインターフェイスを提供した後、実装者はそのインターフェイスに基づいて特定のクラスを実装し、実装者がオリジナルの整合性を破壊することを心配する必要がないからです。プログラムを作成すると、設計者はインターフェイス内のメソッドだけを気にし、具体的なクラス内の補助メソッドについては心配しません。ただし、これには、JAVA クラスの追加などの追加コストがかかります。抽象クラスでは効率が低下する可能性がある場合は、ツール クラスなどの具体的な結合を使用することをお勧めします。