item5 - 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
사용하는 자원에 따라서 동작이 달라지는 그러한 인스턴스 같은 경우에는 새로 생성하지말고 주입받아서 사용하라... 뭐 우선적으로 클래스를 사용하기 위해서 계속해서 인스턴스화를 통해 새롭게 생성해서 사용하는 것은 재사용성도 떨어지며, 자원도 상당히 많이 잡아먹기도 하는 단점이 존재한다
객체를 생성해서 사용하기보다는 내부에 이렇게 선언해두고 사용한다면, Book 이라는 객체가 변화되더라도 Library을 재사용할 수 있다
뭔가 그래서 이상한게 그냥 객체를 생성하나 주입을 하나 메소드가 바뀌면 어쩌나 했었는데, 이게 뭔가 했더니 Book, 즉 주입하는 대상이 interface 인 경우이다 인터페이스이기 떄문에 메소드가 바뀔 일도 없으며 지속적으로 재사용하는 것이 가능하다는 점이다
이걸 조금 더 좋게 사용?하는 방법으로는 의존성(자원)을 직접적으로 생성자에 주입받는 것이 아닌, 의존성(자원)을 만들어주는 Factory 메소드를 생성하는 방법이다 여기서 Supplier 인터페이스를 아래와 같이 사용하는 것이 가장 베스트이다
여기서도 굳이 Book으로 타입을 강제하지 않고, Book은 인터페이스 타입이기 때문에 Book으로 부터 만들어진 모든 객체로 부터 주입받을 수 있게 하기 위해서 Book 관련 타입으로 지정
팩토리 메소드 패턴
팩토리 메소드 패턴의 개념은 이러하다, 부모(상위) 클래스에 알려지지 않은 구체 클래스를 생성하는 패턴이면서 동시에 자식(하위) 클래스가 어떤 객체를 생성할 지 결정하도록 하는 패턴이다 이렇게만 되어도 부모 클래스에서 자식 클래스에 대해서 알 수 없지만 자식 클래스를 사용해서 작업하는 것이 가능하게 된 것이다 부모 클래스가 자식 클래스에 대해서 신경 쓸 일이 없고, 그 의미는 자식 클래스와 부모클래스가 독립적으로 구성되어 있으니 자식 클래스가 변경되더라도 부모클래스에 영향을 끼치지 않는다는 것이다
스프링 IoC
스프링의 기본 철학으로 언급되는 것들 중 하나인데, Inversion of Control으로 제어의 역전을 의미한다 스프링 프레임워크를 사용하게 되면, 우리가 객체를 기존에 사용하는 것처럼 객체를 싱글톤으로 만들어서 자원을 적게 사용하면서 사용하는 그러한 방식을 고려하지 않아도 된다 이렇게 객체에 대한 고민이나 인스턴스의 생성이나 메소드의 실행등을 스프링 프레임워크의 중심인 스프링 컨테이너가 사용자를 대신해서 작동시켜준다는 개념이다
이렇게 스프링 컨테이너가 생성해주는 인스턴스를 보고 빈(Bean)이라고 부른다. 이 빈은 스프링 컨테이너 내부에서 싱글톤으로 관리되고 객체의 라이프사이클 인터페이스를 통해 유지되기 때문에 스프링 컨테이너의 자원에 대한 고민을 조금은 줄여주는 그러한 역할을 도와줄 수 있다. 물론 스프링 컨테이너 외부에서는 작동하지 않는다는점
이렇게 객체를 주입받는 행위는 그럼 사용자로 하여금 주입받는 것들에 대해서 몰라도 되는 상태로 사용하는 것이 가능하며 객체들의 독립성을 보장해주는 역할도 한다
그럼 스프링에서 어떻게 빈으로 등록할까? -> 물론 스프링에는 정말 다양한 애노테이션들이 존재하고, 그 내부 속성을 통해서 파악해보면 빈으로 등록해주는 애노테이션은 정말 많다 하지만 기본적으로는 @Component 이라는 애노테이션을 통해서 빈으로 등록해준다 그리고 등록을 해주었으면, 스프링 컨테이너로 하여금 해당 애노테이션이 붙어있는 클래스를 찾아서 싱글톤으로 만들어서 사용할 수 있게 해야하는데, 그 방식은 스프링 컨테이너의 @Configuration 이라는 애노테이션이 붙은 설정 전용 클래스에 @ComponentScan 이라는 애노테이션을 통해 진행된다 어떤 범위 내에 존재하는 빈을 모두 가져올 것인지를 설정해주는 것도 가능하다
Last updated
Was this helpful?