스프링 객체지향과 다형성

초반에 리포지토리를 구현할 때는 db 연결 없이 해쉬 맵으로 구현했었다. 

멤버 리포지토리 인터페이스를 해쉬맵으로 구현한 멤버 메모리멤버리포지토리 구현체로만 연결 했었다.

 

하지만 이후 h2 데이터 베이스와 연결하기 위해 jdbc 맴버 리포지토리에 새롭게 구현했다.

그래서 멤버 리포지토리의 인터페이스가 두개의 구현체와 연결이 된 상황이 됐다.

 

 

이때, 기존에 멤버 리포지토리와 의존관계가 있는 서비스를 어떻게 처리해야할까?

 

스프링 DI를 이전에 컴포넌트 스캔을 통한 자동 의존 관계 설정(@Autowired) 방식이 아닌, 

자바 코드로 직접 스프링 빈(@Bean)에 등록하면 간단하게 해결할 수 있었다.

 

@Configuration
public class SpringConfig {

    private final DataSource dataSource;

    public SpringConfig(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    @Bean
    public MemberService memberService(){
        return new MemberService(memberRepository());
    }

    @Bean
    public MemberRepository memberRepository(){
        //return new MemoryMemberRepository();
        return new JdbcMemberRepository(dataSource);
    }


}

 

주목해야할 부분은 마지막 리포지토리를 스프링 빈에 등록하는 부분인데, 

기존의 메모리 멤버 리포지토리를 리턴하는 것이 아닌, jdbc멤버리포지토리를 리턴하면

서비스와의 의존관계를 간단히 처리할 수 있었다.

 

이렇게 편리하게 해결해주는것이 스프링의 장점으로 꼽을 수 있다.

 

객체지향적 설계가 좋다.

왜냐?

인터페이스를 두고 구현체 바꿔 끼우기가 가능 (다형성 활용)

스프링은 이것이 편리할 수 있도록 컨테이너가 지원해준다.

 

원래는 멤버 서비스가 메모리 멤버를 의존하는 거에서 jdbc멤버 리포지토리 의존으로 코드를 모두 수정해야한다. (서비스가 여러개면 더 많은 수정이 필요)

 

하지만 여기서는 기존의 코드는 하나도 손대지 않고 어플리케이션 설정하는 부분의 코드만 수정하면 나머지 관련 코드는 건드릴 필요가 없다. (DI 덕분)

 

 

 

 

개방 - 폐쇄 원칙 : 확장(기능 추가)에는 열려있고, 수정/변경에는 닫혀있다.

 

객체 지향의 개념을 잘 활용하면 기능을 완전히 변경해도 기존 코드에 손대지 않아도 된다. (개방 폐쇄의 원칙이 잘 지켜짐)

 

위에서는 스프링의 DI를 이용하여 설정만으로 구현 클래스를 변경해보았다.

 

인터페이스에서 구현체를 바꾸면서도 기존 코드를 바꾸지 않아도 된다는 점이 스프링/객체지향의 아주 큰 장점이라고 할 수 있다.