[AVA-4]DIPとDIについて

悩んだ后はDIとDIPについて书きたい!呜呜呜呜ずっとテーマを変えてるみたい呜...今回はFixを選びます
このテーマは私がNexon Web開発者を面接したときに受けた質問です!では始まります~

DIとDIPについて説明してください。

DIは依存注入を表す.オブジェクトは、内部ロジックから外部オブジェクトにインスタンスを作成して他のオブジェクトを使用するのではなく、外部からインスタンスを入力および使用します.

DIにはコンストラクタ注入とフィールド注入があり、通常は外部で変更可能なコンストラクタ注入を使用することを推奨します.

DIPは依存性逆転の原則を意味する.オブジェクトはインプリメンテーションに依存せず、インタフェースを介してインスタンスを割り当てます.これは、マルチフォーム性の原則を増加させることができることを意味します.

DIPは、拡張に使用できるさまざまな形式を満たし、インタフェースを介して変更、変更、コードの一貫性を維持します.

DIとDIPって何?

Spring Projectを実装する場合は、フィールド注入またはコンストラクション関数注入によってオブジェクトを受信および使用します.
通常、以下のコードに示すように、作成者を注入することによって必要なオブジェクトを受信し、使用します.

private final Book book;

public Study(Book book){
	this.book = book;
}

or

@Autowired
private Book book;

ここのパラメータBookはIOCコンテナによって作成され注入されたオブジェクトです!IOCコンテナでオブジェクトを作成して死亡...
この部分は膨大すぎるので、また今度整理しましょう!
上のコードでは、外部からオブジェクトを注入します...この注入をDI Dependency Injectionと呼ぶ.
上記のコードに示すように、外部注入はStudyというクラスでBookを使用することを可能にする.もちろん、StudyでBookのインスタンスを作成することもできます.

class Study {
	Book book = new Book();
}

or

class Study {
	private Book book;

	public Study(){
		book = new Book();
  }
}

上のコードに示すように、StudyがBookを作成して使用すると、StudyとBookの依存関係の結合度が非常に大きくなります.
依存関係の結合度が増加すると、Bookが変更されると、StudyはBookに関連付けられたすべてのコードの変更に直面します.

class Study {
	private Book book;

	public Study(){
		book = new Book(10, "3만원");
  }
}

上記のコードに示すように、Bookの作成者がnewに変更されたと仮定すると、Studyの作成者もコードの変更に遭遇するトラブルが発生します.ううう
Studyというクラスでオブジェクトを作成および管理する場合は、将来の変更に動的に応答できないという問題に直面します.
従って,外部からの注入により結合結合結合の能動的対応変化を低減するDI Dependency Injectionという機能を実装しなければならない.

フィールド注入と作成者注入およびSetter注入

生成者注入は現場注入より良いと言われていますが、実際にはなぜ良いのか考えたことがありません.今、使わないSetter注入を見てみましょう!

public class Study {
	
	@Autowired
	private Book book;
}

多くの教材でフィールド注入を使用してインスタンスを割り当て、インテリジェント化している場合は、フィールド注入セクションでエラーをチェックできますが、フィールド注入は現在のspringアプリケーションやjavaアプリケーションでは推奨されていない方法です.
フィールドが宣言され、フィールド上に@Autowiredが宣言された場合、外部依存注入を受け入れずにインスタンスを作成し、beanに登録できます.この方式はコードが簡潔な利点がありますが!テストを作成すると、外部注入ができないという困難に直面する可能性があります.また,非抽象的な実装が直接作成されるため,変化に非常に敏感である.
ジェネレータ注入は,外部注入により依存関係を形成する方法であり,以下に示す.

public class Study {
	
	private final Book book;

  public Study(Book book){
		this.book = book;
  }
}

その利点は、実施機関に依存することなく、変化に積極的に対応できることです.
最後に作成した不変オブジェクトは、インスタンスのコピーと比較を容易にし、作成したインスタンスの変更を禁止し、オブジェクトの安全な使用を可能にします.
Setter注入はset()法により作成者に注入する方法である.

public class Study{
	private Book book;

	@Autowired
	public void setBook(Book book){
		this.book = book;
  }
}

これは、bookにインスタンスを注入および作成するための選択的な実施方法である.
もちろん、この方法では、開発者が必要とするときに必要なインスタンスを作成および管理できます.
でも!この場合、Studioオブジェクトのインスタンスを作成したときにset()を返さないと、bookに空の値が得られ、例外が発生する可能性があります.
実行時に問題を解決できないため、この方法は避けることをお勧めします.
次に、インタフェースを介して拡張性を実現する例を示します.

class Study {
	private final Book book;

	public Study(Book book){
		this.book = smallBook;
  }
}

クラスがSmallBookというBookを実現したと仮定します!
Studyでは、Bookの存在だけを知っていても使えます!

Book smallBook = new SmallBook();
new Study(smallBook);

逆に、インスタンスを直接作成すると!

class Study {
	private final Book book;

	public Study(){
		this.book = new SmallBook();
  }
}

Studyでは、Bookを実装したすべてのエンティティをStudyで手動で変更できます.
Studioがインプリメンテーションに依存する場合、Bookインタフェースを実装するすべてのクラスに対して、ジェネレータまたは変換方法を実装することは不便です.
したがって,実装体に直接依存するのではなく,実装体に直接依存するのではなく,SOLIDの最後の原則DIP 2457912の依存性逆転原則を常に暗記することによって,抽象的なクラスに依存し,変更とマルチフォーム拡張に寄与するコードを記述しなければならない.
DIPの概念を使うところは非常に大きい.例えば、SpringではOAuth 2.0でログインすると、

こんなに多くのソーシャルネットワークが存在します.これらのオブジェクトを異なるクラスに実装すると、

public class KaKao{

}

public class Facebook{

}

public class Naver{

}

こんな横暴で理不尽なclassが爆発する!また、サービスで使用する場合は、

public void loginkakao(){
	kakao.login();
}

public void loginNaver(){
	naver.login();
}

public void loginFacebook(){
	facebook.login();
}

多形性の概念はどこにでもあり、コードの長さはますます長くなり、ログインに必要なサービスロジックもますます膨大になります.
したがって,KACA,Facebook,Naverともにログインインタフェースを継承して使用すれば,以降のログインロジックにおいて多形性を保ち,実装に依存しないコードを記述することができる.
最終的には、インタフェース宣言の論理によって、登録サービスはKACA、Facebook、NAVERに依存しなくなった.

public interface Login(){
	void login();
}

public class KaKao implements Login{

}

public class Facebook implements Login{

}

public class Naver implements Login{

}

public void login(){
	login.login();
}

以下は簡単な例で、DIとDIPを簡単に紹介します!

DI.を再整理する場合。

上記のサンプルコードを見ても、非常に困難に感じることがあります.なので酢豚で比較してDIの整理を終了!
酢豚のタレが出てきたので、新しいタレが出てくると、既存のタレを取り除くのに苦労することが多いです.ううう
でも酢豚をつけて食べる場合、新しいソースが出てきたら、いつでも新しいソースをつけて食べることができて、多彩な味を感じることができます!
同様に、DIも外部から入力され、内部ロジックを変更する必要がなく、変更したクラスを設定するだけで問題を解決できるという利点があります.

ではDIPですね。

DIPはフライドチキン屋さんで一番人気のあるフライドチキンは何ですかと聞いているようです
もし私たちがチキン屋に行って一番売れているチキンを注文したら、従業員は私たちにいろいろなチキンメニューの中で何を注文するかと聞きます.
オリジナルチキンを注文したら、あの店で一番売れている味付けチキンは食べられません...
同様にDIPの原則は、チキンのように広範囲のインターフェースを持つことで、味付けチキンやオリジナルチキンといった構想体を得ることができる.
これにより、チキンは味付けチキンやオリジナルチキンのように多様な多形性の機能を発揮することができます.