스프링 기본 - 섹션2,3. 스프링 핵심 원리 이해 - 예제 만들기, 객체 지향 원리 적용

일단 순수 자바로 만든 다음 왜 불편한지 확인 후 스프링을 도입하는 방식으로 진행한다고 한다.

중요하다고 생각한건 DIP를 지키기 위해 구현된 인스턴스가 아닌 인터페이스를 보고 구현한다는 점임.

물론 저렇게 Memory~~ 하면 클래스를 바꿀 때 저 이름도 바꿔야 해서 개방-폐쇄 원칙이 깨진다. 이런걸 수정하면서 스프링을 알아볼 예정.

인터페이스를 도입하게 됨으로써 나중에 새로운 기능이 구체적으로 정해지거나 바뀌어도 똑같은 인터페이스를 사용하기 때문에 상속하는 클래스를 만들고 인스턴스만 갈아끼우면 된다. 그래서 구체적으로 기능을 정하지 않았어도 일단 만드는게 가능하다.

 

 

위 코드를 보면 OrderServiceImpl 인스턴스가 다른 인터페이스만 보는게 아니고 인스턴스도 함께 보기 때문에 OCP 위반이다. DiscountPolicy를 다른걸로 바꾸면 인스턴스에도 의존하고 있었기 때문에 OrderServiceImpl도 바꿔야 한다. 아무것도 아니게 되었음. (자동차 운전면어 땄는데 가스차 운전면허증, 전기차 운전면허증 따로 있는 느낌) 역할에만 의존해야 되는데 역할과 구현 둘 다에 의존하고 있다.

근데 이건 혼자서 어찌 할 수 있는 문제가 아니다. 그래서 AppConfig를 따로 만들고 얘가 알아서 만들어주고 주입해주고 하도록 만들어서 OCP를 지키고, DI를 사용해서 DIP를 지키는 것.

 

 

원래 MemberServiceImpl이 MemoryMemberRepository라는 구체화된 인스턴스의 존재를 알고 의존해서 사용했지만, 이제 DI로 바꾼다. 주입은 AppConfig가 해주도록 한다. 그럼으로써, MemberService는 인터페이스라는 존재만 알고 사용하게 되어서 이제 MemberRepository라는 인터페이스만 알면서 구현하여 DIP를 지키고, MemberRepository 구체화 인스턴스를 다른걸로 바꿔도 코드는 전혀 바꾸지 않으므로 OCP도 지킨다.

이렇게 AppConfig처럼 객체를 생성하고 관리하면서 의존관계를 연결해 주는 것을 IoC컨테이너 또는 DI 컨테이너 라고 한다.

 

 

그럼 이제 구체화 인스턴스 방식을 바꾸더라도 AppConfig의 한줄만 바꾸면 된다. 이는 모든 서비스들에서 AppConfig를 일일히 만들어서 해줬으니까 가능한 것.

 

 

그럼 여기서 이제 정적 다이어그램과 객체 다이어그램으로 분리됨을 알아야 한다. 앱 입장에서는 모든게 인터페이스로만 의존하기 때문에 실제 동작할 때 어떤 인스턴스에 의존하게 되는지 모른다. 그래서 따로 있는 것.

 

 

 

 

이걸 이제 스프링으로 바꾸자.

 

@Bean을 하게 되면 스프링을 실행할 때 일단 @Bean으로 되어있는 모든 크래스를 다 순회하여 컨테이너에 들록한다. 실제로 저 메소드 명으로 컨테이너에 등록됨.

 

등록된 걸 꺼낼 때 꺼낼 이름이랑 형식을 주면 된다. 스프링의 모든건 Context로 시작한다고 함.