Spring에서 인터페이스를 사용하는 프로그래밍(programming to interface)이 좋은 이유

Java의 Interface는 구현 클래스가 준수해야 하는 계약을 정의한다.

따라서 클래스가 의존 관계를 구현하는 Interface에 의존한다면, 해당 의존 관계의 구현을 변경하더라도 의존 중인

클래스를 변경할 필요가 없다.

 

이런 식의 의존 중인 클래스가 의존 관계가 구현하는 Instance로 의존성을 만드는 설계 원칙을

'인터페이스를 사용하는 프로그래밍' (programming to interface)이라 한다.

이 방식은 의존 중인 클래스와 의존 관계 사이에 느슨한 결합을 만든다.

의존 관계 클래스가 구현하는 인터페이스를 의존 관계 인터페이스 (dependency Interface) 라고 부른다.

 

말이 좀 어려운데 그림을 통해서 써보겠다.

 

MemberService의 의존 관계

MemberService가 1번처럼 JDBC를 사용하다가 2번으로 바꾼다고 하면 아래와 같이  MemberService에서 직접 의존하는 것을 모두 바꿔줘야 한다.

@Service
public class MemberService {
	// 기존의 Dao
	private final MemberJDBCDao jdbcDao;
    // 변경할 Dao
    private final MemberHibernateDao hibernateDao;
	
    //기존 생성자
	MemberService(MemberJDBCDao jdbcDao){
    	this.jdbcDao = jdbcDao;
    }
    //바꿔야 할 생성자
    MemberService(MemberHibernateDao hibernateDao){
    	this.hibernateDao = hibernateDao;
    }
    // 회원 가입하고 회원 번호를 return 해 주기 위한 메소드
    public Integer joinMember(JoinMemberRequestDto joinDto){
    	jdbcDao.join(joinDto); // --> hibernateDao.join(joinDto)로 고쳐야 됨
    }
}

위의 예제는 1개 밖에 없지만 실제로 MemberService에서는 몇개가 될 수도 있고 100개가 넘을 수도 있다.

그러면 모두 바꿔줘야 한다.

만약에 또 다른 것으로 바꾼다면?? 또 바꿔야 해??

 

클래스를 의존하는 형식으로 하게 된다면 의존도가 강하게 되면서 유지/보수에 어려움이 있다.

 

Interface를 의존했을 때는 어떻게 될까??

MemberDao를 Interface로 만들었을 때

MemberService는 MemberDao  Interface에 의존하기 때문에 MemberDao를 상속받은 HibernateDao나, JDBCDao 중 어떤 것이 와도 상관이 없어진다.

 

때문에 Class를 의존하는 것보다는 Interface를 의존하는 방식을 사용하는 쪽으로 가는 것이 효율적이 된다.