[xml] 의존성 주입 컨테이너의 이점은 무엇입니까?

의존성 주입 자체의 이점을 이해합니다. 예를 들어 Spring을 보자. 또한 AOP, 다른 종류의 도우미 등과 같은 다른 Spring 기능의 이점을 이해합니다. 다음과 같은 XML 구성의 이점이 무엇인지 궁금합니다.

<bean id="Mary" class="foo.bar.Female">
  <property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
  <property name="girlfriend" ref="Mary"/>
</bean>

다음과 같은 일반 오래된 자바 코드와 비교 :

Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);

디버깅이 더 쉽고 컴파일 시간이 확인되며 java 만 아는 사람이라면 누구나 이해할 수 있습니다. 그렇다면 의존성 주입 프레임 워크의 주요 목적은 무엇일까요? (또는 그 이점을 보여주는 코드입니다.)

UPDATE :
의에서 케이스

IService myService;// ...
public void doSomething() {
  myService.fetchData();
}

IoC 프레임 워크가 둘 이상의 myService 구현을 주입 할 것인지 추측 할 수 있습니까? 주어진 인터페이스의 구현이 하나 뿐이고 IoC 컨테이너가 자동으로이를 사용하도록 결정하면 두 번째 구현이 나타난 후 중단됩니다. 그리고 의도적으로 인터페이스의 가능한 구현이 하나만있는 경우이를 삽입 할 필요가 없습니다.

IoC의 이점을 보여주는 작은 구성을 보는 것은 정말 흥미로울 것입니다. 나는 한동안 Spring을 사용 해왔고 그러한 예를 제공 할 수 없다. 그리고 내가 사용하는 최대 절전 모드, dwr 및 기타 프레임 워크의 이점을 보여주는 단일 행을 표시 할 수 있습니다.

업데이트 2 :
IoC 구성을 다시 컴파일하지 않고도 변경할 수 있음을 알고 있습니다. 정말 좋은 생각인가요? 누군가가 재 컴파일하지 않고 DB 자격 증명을 변경하려는 경우 이해할 수 있습니다. 개발자가 아닐 수도 있습니다. 실제로 개발자가 아닌 다른 사람이 IoC 구성을 얼마나 자주 변경합니까? 개발자에게는 구성을 변경하는 대신 특정 클래스를 다시 컴파일하려는 노력이 없다고 생각합니다. 그리고 개발자가 아닌 경우에는 그의 삶을 더 쉽게 만들고 더 간단한 구성 파일을 제공하고 싶을 것입니다.

업데이트 3 :

인터페이스와 구체적인 구현 간의 매핑에 대한 외부 구성

그것을 확장하는 데 무엇이 그렇게 좋은가요? 모든 코드를 외부로 만들지는 않지만, 확실히 할 수 있습니다. ClassName.java.txt 파일에 넣고 즉시 수동으로 읽고 컴파일합니다. 와우, 재 컴파일을 피했습니다. 왜 컴파일을 피해야합니까?!

절차 코드가 아닌 선언적으로 매핑을 제공하므로 코딩 시간이 절약됩니다.

때때로 선언적 접근 방식이 시간을 절약한다는 것을 이해합니다. 예를 들어 빈 속성과 DB 열 사이의 매핑을 한 번만 선언하고 최대 절전 모드에서는 HSQL을 기반으로 SQL을로드, 저장, 빌드하는 동안이 매핑을 사용합니다. 여기서 선언적 접근 방식이 작동합니다. Spring의 경우 (제 예에서) 선언에는 더 많은 줄이 있고 해당 코드와 동일한 표현력을 가졌습니다. 이러한 선언이 코드보다 짧은 예가 있다면보고 싶습니다.

Inversion of Control 원칙을 사용하면 실제 구현을 가짜 구현으로 대체 할 수 있기 때문에 쉽게 단위 테스트가 가능합니다 (예 : SQL 데이터베이스를 메모리 내 구현으로 대체).

제어의 역전 이점을 이해합니다 (여기서 논의한 디자인 패턴을 종속성 주입이라고 부르는 것을 선호합니다. 왜냐하면 IoC가 더 일반적이기 때문입니다-많은 종류의 제어가 있고 그중 하나만 반전하고 있습니다-초기화 제어). 나는 왜 누군가가 그것을 위해 프로그래밍 언어가 아닌 다른 것을 필요로하는지 물었다. 코드를 사용하여 실제 구현을 가짜 구현으로 대체 할 수 있습니다. 그리고이 코드는 구성과 동일한 것을 표현합니다. 단지 가짜 값으로 필드를 초기화합니다.

mary = new FakeFemale();

DI의 이점을 이해합니다. 동일한 작업을 수행하는 코드를 구성하는 것과 비교하여 외부 XML 구성에 의해 추가되는 이점을 이해하지 못합니다. 나는 컴파일을 피해야한다고 생각하지 않는다. 나는 매일 컴파일하고 여전히 살아있다. DI의 구성은 선언적 접근의 나쁜 예라고 생각합니다. 선언은 한 번 선언하고 다른 방식으로 여러 번 사용하면 유용 할 수 있습니다.-hibernate cfg와 같이 빈 속성과 DB 컬럼 간의 매핑이 검색 쿼리 저장,로드, 빌드 등에 사용됩니다. Spring DI 구성은 쉽게 번역 할 수 있습니다. 이 질문의 시작 부분과 같이 코드를 구성 할 수 있습니까? 그리고 빈 초기화를 위해서만 사용되는 것 아닌가요? 이것은 선언적 접근 방식이 여기에 아무것도 추가하지 않는다는 것을 의미합니까?

hibernate mapping을 선언 할 때, hibernate에 몇 가지 정보를 제공하고이를 기반으로 작동합니다. 무엇을해야하는지 알려주지 않습니다. 봄의 경우, 내 선언은 봄에 정확히 무엇을해야하는지 알려줍니다. 왜 그것을 선언하고, 왜 그렇게하지 않습니까?

마지막 업데이트 :
여러분, 많은 답변이 의존성 주입에 대해 말해주고 있습니다. 문제는 코드를 초기화하는 대신 DI 구성의 목적에 관한 것입니다. 코드 초기화가 더 짧고 명확하다고 생각하는 경향이 있습니다. 지금까지 내 질문에 대한 유일한 대답은 구성이 변경 될 때 재 컴파일을 피한다는 것입니다. 나는 다른 질문을 게시해야한다고 생각한다. 그것은 나에게 큰 비밀이기 때문에 왜이 경우 컴파일을 피해야 하는가.

답변

<bean id="base" parent="RootXFireBean">
    <property name="secondProperty" ref="secondBean" />
</bean>

<bean id="secondBean" parent="secondaryXFireBean">
    <property name="firstProperty" ref="thirdBean" />
</bean>

<bean id="thirdBean" parent="thirdXFireBean">
    <property name="secondProperty" ref="myNewBean" />
</bean>

<bean id="myNewBean" class="WowItsActuallyTheCodeThatChanged" />

public class TheFirstPointlessClass extends SomeXFireClass {
    public TheFirstPointlessClass() {
        setFirstProperty(new TheSecondPointlessClass());
        setSecondProperty(new TheThingThatWasHereBefore());
    }
}

public class TheSecondPointlessClass extends YetAnotherXFireClass {
    public TheSecondPointlessClass() {
        setFirstProperty(TheThirdPointlessClass());
    }
}

public class TheThirdPointlessClass extends GeeAnotherXFireClass {
    public TheThirdPointlessClass() {
        setFirstProperty(new AnotherThingThatWasHereBefore());
        setSecondProperty(new WowItsActuallyTheCodeThatChanged());
    }
}

public class WowItsActuallyTheCodeThatChanged extends TheXFireClassIActuallyCareAbout {
    public WowItsActuallyTheCodeThatChanged() {
    }

    public overrideTheMethod(Object[] arguments) {
        //Do overridden stuff
    }
}