🌏DI(Dependency Injection)의 원리

• 설정 파일(xml) 또는 어노테이션을 통해 객체간 의존 관계 설정
• 객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요 없음
• 객체를 생성할 때 new키워드를 통해서 생성하면, 추후 클라이언트의 요구사항이 변경되었을경우, 대부분의 소스를 수정해야 한다. 하지만 스프링 프레임워크를 적용하여 xml파일에서 설정만 해주면 외부설정파일(xml)에서 연관 관계에 있는 객체(DTO)를 넣어 주기 때문에 의존 객체를 찾기 위한 코드가 불필요하다
  즉, 외부설정에서 객체를 찾아서 사용하기 때문에 코드내의 의존 관계를 맺는 코드생성을 할 필요가 없다. 의존(Dependency)하는 객체를 외부설정에서 삽입(Injection)하기 때문에 DI패턴이라고 한다

1. 객체를 직접 생성하여 사용하는 과정

public class ClassA{

public void process(){
   ServiceA sa = new ServiceA();
   ServiceA sb = new ServiceB();
}
}

장점: 개발자가 OOP에 대한 설계 개념이 부족해도 이해하고 활용 가능한 구조입니다.

단점: 팀 작업을 할 때 표준화가 어렵다. 개발자가 제각각 개발 패턴을 이용함으로 관리상에 많은 비용이 발생합니다.

2. 인터페이스

ICompany coma = new CompanyA();
ICompany comb = new CompanyB();

장점: 개발자가 표준적인 API를 사용하게 됨으로 프로젝트의 규모가 커져도 관리상에 편리함이 발생한다.
팀 작업이 가능하다. 인터페이스는 구현하지 않으면 에러가 발생함으로 모든 개발자가 같은 패턴을 사용하게 됩니다.
관리 비용이 적게 들어갑니다.

단점: 개발자가 OOP를 알아야함, 객체 디자인 패턴에 대한 지식이 있어야 함, 개발 경험이 있어야 사용이 편리해짐.
빈(객체)을 개발자가 직접 생성하여 사용하는 문제는 존재함.

3. Factory Pattern

• 객체를 만드는 메소드를 전문적으로 구현한 경우 Factory Method pattern이라고 합니다.
  • 객체를 만드는 Class를 전문적으로 구현한 경우 Factory Class pattern이라고 합니다.
  • 장점: 객체를 생성하는 곳이 중앙으로 통제되고있어 프로젝트의 규모가 커져도 클래스 통제가 수월합니다.
  • 단점: 개발자가 객체 생성 관련 로직을 전부 구현해야 합니다. 예)

    public Object makeProcess(String code){
    Object obj = null;
    
    if (code.equals("A01"){
       obj = new A01();
    }else if (code.equals("B01"){
       obj = new B01();
    }else{
      obj = new A02();
    }
    
    return obj;
    }