A 객체에서 B 인터페이스 구현체가 멤버로 필요한데 구현체를 타입으로 지정하면 추상화가 아니라 구체화에 의존하게 되기때문에 나중에 같은 인터페이스를 구현하는 C 구현체로 교체하려고 할때 A의 코드도 함께 변경해줘야 함, A객체는 그냥 인터페이스 사용법만 알면 되지 그게 B든 C든 알빠노인데 구체화에 의존하면 너무 많은 정보와 책임이 따름 스프링 DI는 컨픽 또는 어노테이션을 통해 생성되는 빈의 의존관계를 파악하고 애플리케이션컨텍스트(빈 팩토리)가 로드되고 빈을 생성할 때 각 빈들에 필요한 의존성 주입을 해주고 그게 바로 제어의 역전임 개발자가 의존성 주입을 해주는게 아니라 프레임웍이 알아서 착착 해주는것
다 틀림 - dc App
그럼 뭐임? 확장성이랑 스프링빈이 관리해줘서 쓴느거 아님?
class Foo { Bar b = new Bar() } 대신에 class Foo { Bar b; } Foo f = new Foo(new Bar()) 이런게 의존성 주입 이제 bar이 인터페이스면 더 유연한거고
근데 이것도 new A(new B(new C(new D(new E .... ))))) 이렇게 수동으로 하다보면 정신나갈 것 같으니까 대신 해주는게 스프링(IoC Container)
여기서 각 인스턴스가 stateless면 여러 인스턴스를 만들 필요가 없으니 싱글톤으로 관리하고, 이게 권장사항
쓰레드 세이프하게 final로 지정해주고 거기에 싱글톤타입 빈을 주입하는거라 생각하면됨 디폴트가 싱글톤인데 프로토타입으로도 생성함
A 객체에서 B 인터페이스 구현체가 멤버로 필요한데 구현체를 타입으로 지정하면 추상화가 아니라 구체화에 의존하게 되기때문에 나중에 같은 인터페이스를 구현하는 C 구현체로 교체하려고 할때 A의 코드도 함께 변경해줘야 함, A객체는 그냥 인터페이스 사용법만 알면 되지 그게 B든 C든 알빠노인데 구체화에 의존하면 너무 많은 정보와 책임이 따름 스프링 DI는 컨픽 또는 어노테이션을 통해 생성되는 빈의 의존관계를 파악하고 애플리케이션컨텍스트(빈 팩토리)가 로드되고 빈을 생성할 때 각 빈들에 필요한 의존성 주입을 해주고 그게 바로 제어의 역전임 개발자가 의존성 주입을 해주는게 아니라 프레임웍이 알아서 착착 해주는것