第3週DI、IOC、POJO

DI, IoC, POJO
各キーワードの意味
各キーワードの例について
以前はオブジェクト向けプログラミングを習っていました.
スプリングフレームにおけるスプリング三角形IOC/DI、AOP、PSA
スプリング三角形は、3種類の振動を配置オブジェクト(POJO)に増幅することで巨大なフレームを完成させる.
**画像を添付してください
第7章注入p.234 IoC/DI-制御の逆転/依存性
スプリング制御/制御反転(IOC)と呼ばれる依存注入を知る前に,プログラミングにおける依存性とは何か.Javaでの依存性は?
->Java依存性に関連する、知らない単語と概念-クラス、構造関数、オブジェクト、方法、関数(区別方法と関数)、そしてマーチ:argsこれは何ですか.ブラウズ
「依存注入」(Dependency Injection)とは、スプリングが他のフレームと異なることを意味する.
オブジェクトを直接生成するのではなく、外部からオブジェクトを生成して注入する方法です.
依存注入(DI)により,モジュール間の結合度が低下し,柔軟性が向上した.
Springでは、オブジェクトをbeanと呼び、プロジェクトの実行時にbeanによって管理されるオブジェクトの作成と破棄に関する操作をユーザーが自動的に実行できますが、Springではオブジェクトが作成される場所をbeanコンテナと呼びます.

1つ目の方法は、AオブジェクトがNewジェネレータを介して直接BオブジェクトとCオブジェクトを作成することです.
2つ目の方法は、setter()によって外部で生成されたオブジェクトを使用することです.
第2の方法は依存注入の例である.
AオブジェクトにB、Cオブジェクトを使用(依存)する場合、直接Aオブジェクトから生成するのではなく、外部(IOCコンテナ)から生成されたB、Cオブジェクトによって組み立て(注入)、setterまたはジェネレータによって使用される方式です.
すなわち,DIはクラス間の依存関係を空の設定情報に基づいてコンテナによって自動的に関連付ける.開発者にとって、制御を担当する必要はなく、空のプロファイルに依存関係が必要な情報を追加するだけです.次に、外部(Container)からオブジェクトリファレンスを入力し、実行時に動的に依存関係を作成します.最終的に,コンテナはストリームの主体となり,アプリケーションコードに依存関係を注入する.
Ioc(Inversion of Control)
IoC(Inversion of Control)は、「制御の逆転」を意味し、すなわち、メソッドまたはオブジェクトの呼び出しは、外部ではなく開発者によって決定される.

IoCは制御の逆転と言い、簡単に言えば「制御の流れを変える」と言います.
オブジェクトの依存性を逆転させることで、オブジェクト間の結合度を低減し、柔軟なコードを書くことができ、可読性とコードの繰り返しとメンテナンスを容易にします.
既存のオブジェクトは、次の順序で作成および実行されます.
1.オブジェクトの作成
2.依存オブジェクトの作成
クラスでの作成
3.依存オブジェクトメソッドの呼び出し
ただし、スプリングでは、オブジェクトの作成と実行の順序は次のとおりです.
1.オブジェクトの作成
2.依存オブジェクトの注入
自分で作成するのではなく、スプリングにコントロールを委任して、スプリングで作成したオブジェクトを注入します.
3.依存オブジェクトメソッドの呼び出し
スプリングは、スプリングの実行時にすべての依存オブジェクトを作成し、必要な位置に注入して、beanが単一回転モードの特徴を持つようにします.
制御フローは、ユーザによって制御されるのではなく、スプリング処理に渡される.
IoC/DI未適用のコードとアプリケーションのコード例を見てみましょう.

package kr.co.hangbok;

public class Foo{
	private Bar bar;
    
    public Foo() {
    	bar = new SubBar();
    }
  }

上記のコードにはIoC/DIはありません.この場合、アプリケーションコードは直ちにBarインタフェースを実装する特定のクラスの名前(SubBar)を使用して初期化されます.この場合,実装クラスを動的に特定することは困難である.
以下に、IoC/DIを用いたコード例を示す.

//컨테이너
<beans>
	<bean id="bar" class="kr.co.hangbok.SubBar">
    <bean id="foo" class="kr.co.hangbok.Foo">
    	<property name="bar" ref="bar"/>
    </bean>
</beans>

//애플리케이션 코드
package kr.co.hangbok;

public class Foo {
	private Bar bar;
    
    public void setBar(Bar bar) {
    	this.bar = bar;
    }
}

IOC/DIが適用される場合、まず使用するオブジェクトをコンテナに登録します.次に、setter関数としてオブジェクトのパラメータをアプリケーションコードから取得し、実行時に動的に依存関係を確立します.この場合、Barインタフェースを実装する特定のクラスの名前はアプリケーションコードに表示されないので、実装クラスを動的に決定することができる.
したがって、IoC/DIを使用すると、オブジェクトを作成する際に、アプリケーションコードの外部(Container)にオブジェクトが参照する他のオブジェクトの依存関係を設定することで、結合性を低下させながら柔軟性と拡張性を向上させることができます.
参照-結合https://ko.wikipedia.org/wiki/%EA%B2%B0%ED%95%A9%EB%8F%84
POJO
POJOはPlain Old Java Objectの略で、メソッドを追加するのではなく、他のクラスやインタフェースを継承/実装するクラスを指し、通常は私たちが知っているgetter、setterなど基本機能のみを持つJavaオブジェクトです.
POJOの目的は,Javaのオブジェクト指向の特徴を利用して,ビジネスロジックの充実した開発を可能にすることである.
複雑な開発ニーズを満たすためには,POJOベースのフレームワークを適切に使用する必要がある.POJOフレームワークを簡単に使うのではなく、複数の基準を遵守します.
行きましょう.オブジェクト向けの設計原則を満たすように開発する
POJOはオブジェクト向けの言語で、Javaオブジェクトの特徴を持たなければならない.
テストが困難な構造、拡張、または回収は困難ではありません.
私.簡単なテスト
POJO哲学を用いて作成されたアプリケーションは、テストコードの作成を自動化するのに便利であるべきである.

public class User {
    private int id;
    private String name;
    private String email;
    
    public int getId() {
    	return id;
    }
    public String getName() {
    	return name;
    }
    public String getEmail() {
    	return email;
    }
    
    public void setId(int id) {
    	this.id = id;
    }
    public void setName(String name) {
    	this.name = name;
    }
    public void setEmail(String email) {
    	this.email = email;
    }
}

上記のクラスをJavaの基本オブジェクトと呼びます.(POJOはGetterとSetterからなる最も純粋な基本タイプ)
Javaを使用してビジネス・サービスを開発する際にビジネス・ロジックだけでなく、トランザクション、セキュリティなどのログ・ロジックを作成する負担を解消するために、エンタープライズ・Java Beansを作成しました.EJBを使用するとLowbellロジックの開発作業量を減らすことができますが、1つまたは2つの機能を使用するために大きなEJBが継承または実現されるため、単純なサービスでも重いという問題が発生し、他の機能に代わるためにコード全体を修正する必要があります.
JAVAの基本概念をオブジェクト向けに集中し,特定のクラスやライブラリに依存しないPOJO構成を用いてコードを記述すれば,これらの問題を解決できると考える.
そこでSpringは、IoC、DI、AOPなどのSpringのキーテクノロジーを活用したPOJOベースのWebフレームワークであり、POJOベースの構成を実現しています.
JAVAにはPOJOクラスに従う必要のない制限条件が3つあります.
1.定義済みクラスの拡張

    public class Foo extends javax.servlet.http.HttpServlet { ...

事前定義インタフェース実装

public class Bar implements javax.eib.EntityBean { ...

は、予め定義する注釈

を含む.

@javax.persistence.Entity public class Baz { ...

POJOコンセプトを使うか使わないかは?

表示例を強調するために、SpringフレームワークでJMS(Java Message Service)のMessageListerからメッセージを受信する例を見てみましょう.

コンセプトなし

public class ExampleListener implements MessageListener {

  public void onMessage(Message message) {
    if (message instanceof TextMessage) {
      try {
        System.out.println(((TextMessage) message).getText());
      }
      catch (JMSException ex) {
        throw new RuntimeException(ex);
      }
    }
    else {
      throw new IllegalArgumentException("Message must be of type TextMessage");
    }
  }

}

JMSを使用するにはMessageListenerインタフェースを継承する必要があります.
しかし、JMSは特定の環境の一部であり、他のメッセージングソリューションを適用することが困難であるため、簡単な例とは異なり、Listenerが多い場合、他のソリューションで置き換えることはさらに困難である.

コンセプト

@Component
public class ExampleListener {

  @JmsListener(destination = "myDestination")
  public void processOrder(String message) {
    System.out.println(message);
  }
  
}

逆に,POJO概念を用いたコードから見ると,どのインタフェースにも依存しない.
@JmsListenerという名前のツールを使用してJMSサービスを利用できますが、他のソリューションを利用する場合は@RabbitListerに変換するだけです.
上記の例に示すように、スプリングフレームは、ライブラリとの結合性を低減するのに役立ちます.
出典)DI、Beanとは?https://velog.io/@gillog/Spring-DIDependency-Injection
IOC/DIを適用したコード、未適用のコード
https://www.nextree.co.kr/p11247/
POJOの基本特性
https://velog.io/@galaxy/Spring%EC%9D%98-%EA%B8%B0%EB%B3%B8-%ED%8A%B9%EC%A7%95-POJO
Wiki百科事典のplain old java object
POJO関連(概念とサンプルコード):https://codedot.co.kr/5[私心に満ちた記録]