스프링 기초편의 초식 DI와 AOP

앞말
자바 개발에 종사하는 코드 농부로서 스프링의 중요성은 말하지 않아도 알 수 있다. 당신은 매일 스프링 프레임워크와 접촉하고 있을 것이다.스프링은 이름처럼 자바 응용 프로그램 개발에 봄처럼 시원한 느낌을 준다.Spring은 모든 자바 개발자가 기술 고급으로 나아가는 데 필수적인 기초라고 할 수 있다.물론 스프링을 잘 배워야 한다. 특히 스프링의 밑바닥 원리를 이해하는 것은 쉽지 않다. 많은 시간과 정력을 들여 전심전력으로 연구하고 실제 프로젝트에서 끊임없는 시행착오와 총결을 해야만 자신만의 사유 이해를 형성할 수 있다.블로거들은 스프링에 대한 최초의 인식이 얕았기 때문에 프로젝트에서 문제에 부딪히면 도모에게 의지해서 아마도 일괄적으로 해결할 수 있을 것이다.그러나 스프링을 접촉한 지 1년여 동안 그 구조 체계에 대한 인지가 비교적 난잡하고 심층 기술은 여전히 안개 속에서 꽃을 보는 것처럼 자신의 인지와 이해를 형성하지 못했기 때문에 프로그래밍 기술의 향상에 매우 불리하다.이를 감안하여 마음을 가라앉히고 처음부터 끝까지 체계적으로 스프링 프레임워크를 배우고 블로그 형식을 통해 방울을 기록하며 기술 지식을 공유하기로 한 것은 벽돌을 던져 옥을 끌어올리는 셈이다.자, 잡담은 그만두고 본론으로 들어가자―
Spring 프레임워크 핵심 소개
DI(Dependency Injection)는 주입에 의존하고 우리가 흔히 듣는 또 다른 개념인 IOC(반전제어)와 사실상 실현된 기능은 같다. 단지 같은 기능은 서로 다른 각도에서 논술할 뿐이다.이곳의 블로거들은 많은 분석을 하지 않았고, 도모에게는 많은 해석이 있었다.우리가 알아야 할 것은 의존 주입이 무엇인지, 왜 의존 주입이 무엇인지이다.이 두 가지를 잘 알면 스프링에 대한 공부는 사상적으로는 상책이라고 할 수 있다.
Spring을 사용하지 않을 때 - 즉 주입에 의존하지 않을 때 자바 응용 프로그램의 클래스와 클래스 간에 상호적인 기능 협업을 실현하는 것은 비교적 어렵다. 어떤 클래스(A)가 그 기능을 실현하려면 다른 클래스(B)의 협업에 의존해야 한다면 A클래스에서 B클래스의 대상을 주동적으로 만들어야 한다.B류의 방법으로 기능을 완성할 수 있다.이것은 클래스 A가 클래스 B의 전체 라이프 사이클을 관리해야 하는 것과 같다.극도로 간단한 상황에서 한 클래스에서 new가 다른 클래스를 만드는 대상은 아무런 문제가 없는 것 같지만 복잡한 응용 프로그램 클래스와 클래스의 협업 관계는 종종 다각적이다. 우리는 하나의 클래스 기능의 실현이 몇 개의 다른 대상에 의존하여 협업할지 모른다. 그래서 클래스에서 자체적으로 대상을 만들고 대상의 전체 생명 주기를 관리하면 코드의 높은 결합과 상상할 수 없는 복잡도를 초래할 수 있다.그러면 만약에 우리가 대상의 생명주기를 제3자 구성 요소에 맡겨서 관리할 수 있다면 어떤 종류가 다른 대상을 필요로 할 때 제3자 구성 요소를 직접 만들어서 그에게 건네주면 클래스는 자신의 기능의 실현에만 전념할 수 있고 다른 종류의 대상의 생명주기를 관리하지 않아도 된다. 이런 종류의 기능은 매우 단순하다.그래, 너는 틀림없이 이미 알고 있을 거야. 스프링이 바로 이 제3자 구성 요소야.우리는 스프링 프레임워크가 어떻게 대상을 만드는지 신경 쓰지 않고 스프링 (용기) 에 어떤 대상을 관리해야 하는지 알려주면 된다.이렇게 하면 클래스 A가 클래스 B 대상을 필요로 할 때 클래스 B가 Sping 용기 관리에 맡겼다고 성명하면 프로그램이 클래스 A에 클래스 B를 필요로 할 때 스프링 용기는 주입에 의존하는 방식으로 클래스 B 대상을 클래스 A에 주입하여 업무 기능을 완성하는 데 협조한다.제3자 구성 요소의 의존 주입을 통해 대상은 더 이상 자체적으로 클래스와 클래스 간의 의존 관계를 창설하고 관리할 필요가 없다.대상의 창설 의존 주입 방식도 여러 가지가 있는데 예를 들어 인터페이스 주입, 구조 방법 주입,setter 방법 주입 등이다.여기까지 말하면 의존 주입에 대해 비교적 직설적인 인식을 가져야 한다.왜 주입에 의존해야 하는지에 대해 위에서 분명히 말한 바와 같이 코드에서 구성 요소 간의 결합도를 줄이기 위해서 우리는 먼저 간단한 예시를 통해 주입에 의존하는 것이 자신의 관리 대상보다 좋은 점을 직관적으로 느끼자.

public class Man implements Human {
  private QQCar car;
  public Man() {
    this.car = new QQCar();
  }
  @Override
  public void xiabibi() {
  }
  public void driveCar(){
    car.drive();
  }
}

인터페이스 Car는 잠시 두 가지 실현이 있다. 벤츠차와 QQ차, 상기 맨클래스와 QQCar류가 고도로 결합된 코드에서 낡은 기사는 구조기를 통해 QQ차 대상만 만들었기 때문에 QQ차만 운전할 수 있다. 그러면 낡은 기사가 벤츠를 운전하려면 어떻게 해야 한다. 당신은 그에게 벤츠차의 대상을 다시 만들라고 합니까?이렇게 고도로 결합된 코드는 어쩔 수 없는 것 같다. 그러면 우리는 대상을 주입하는 방식으로 상술한 코드를 개선한다.

public class Man implements Human {
  private Car car;
  public Man(Car car) {
    this.car = car;
  }
  @Override
  public void xiabibi() {
  }

  public void driveCar() {
    car.drive();
  }
}

상기 코드는 다태적 특성에 따라 구조기 인터페이스를 통해 주입하는 방식으로 구체적인 대상을 차단하여 실현시켰다. 그러면 늙은 운전자는 운전하고 싶은 대로 운전할 수 있다.이것이 바로 주입에 의존하는 것이 가져오는 장점이다.
절단면 프로그래밍을 위한 AOP(Aspect Oriented Programming)일상적인 개발에서 우리는 특정한 업무 기능을 완성할 때 코드를 한 무더기 썼다. 마지막 코드가 최적화될 때 진정으로 업무를 완성하는 코드는 그 두 마디일 수 있고 나머지는 모두 이 부분의 업무와 관련성이 크지 않다. 단지 특정한 기술을 실현하기 위한 코드일 뿐이고 완전히 추출할 수 있기 때문에 자연스럽다. 우리는 이를 하나의 도구류로 추출할 것이다.이렇게 하면 무릇 사용하는 곳은 공구 방법을 호출하면 ok가 된다.우리가 좀 더 높이 서서 보면 각 업무 모듈의 기능 구성 요소 중에는 관련 업무 기능을 완성하는 것 외에 로그, 사무, 안전 제어 등 추가 조작과 관련된 것이 있다.이것들은 모듈의 핵심 기능은 아니지만 부족하거나 없어서는 안 된다.만약 이러한 추가 기능을 코드에 추가한다면 업무 시스템의 모든 구성 요소는 너무 중복되고 업무 코드를 혼란스럽게 하며 순수하지 않다.이때 당신은 하느님께 당신의 업무 코드가 업무의 실현에만 전념하고 어떤 일지, 사무 등 상관없는 일에 관여하지 않도록 할 수 있습니까?오, 하느님이 괜찮다고 하셔서 AOP가 생겼어요.주입에 의존하는 목적이 서로 협력하는 구성 요소가 비교적 느슨한 결합 상태를 유지하도록 하는 것이라면, AOP는 곳곳에 널리 퍼져 있는 기능을 분리하여 다시 사용할 수 있는 구성 요소를 형성한다.통속적으로 말하자면 로그, 사무 등은 모두 다시 사용할 수 있는 구성 요소이다. 우리는 업무 코드 곳곳에 분산된 로그, 사무, 안전 등 기능 코드를 하나의 단독 도구 구성 요소로 추출할 수 있다. 스프링의 설정에서 이를 하나의 기능 절단면으로 성명하고 스프링이 어떤 곳, 어떤 시기에 사용하고 싶은지 알려주면 된다.이것이 바로 내 맞은편 절단면의 간단한 해석이다.이 편은 인용문일 뿐이기 때문에 블로거들은 개념을 간단하게 논술하고 구체적인 코드, 설정 실현을 하지 않으며 후속적인 블로그에 벽돌을 찍는 것을 환영합니다.