[java] interface의 진짜 목적

결론부터말하면 Interface는 abstract method로만 구성된 클래스로써 추상체로 역할을 하며 구현체와 호출하는 쪽 사이의 dependency를 느슨하게 한다. 특히 의존성을 역전(Dependency Inversion)시킴으로써 객체 간 결합도(coupling)를 줄인다.

 

[예제1]

public class UserService implements Login{
    private KakaoLogin login;
    private NaverLogin login;

    // 이하 생략
}

[예제2]

public class UserService implements Login {
    private Login login;

    public UserService(Login login) {
        this.login = login;
    }

    @Override
    public void login() {
        login.login();
    }
}

 

[예제1]과 [예제2] 코드의 가장 큰 차이점은 UserService 객체와 각 Login 객체와의 의존도(dependency) 정도의 차이이다. [예제1]의 경우 UserService 객체는 KakaoLogin 객체와 NaverLogin 객체에 직접적으로 의존하고 있어 의존도가 높은 코드이다.(bad code)

 

하지만 [예제2]의 경우 KakaoLogin, NaverLogin 클래스가 각각 Login 인터페이스를 implements 하도록 하고 Login 인터페이스 타입으로 갖고 있고, 어떤 Login 객체와 dependency를 가질 지에 대해서는 생성자 부분에서 외부로부터 주입받도록 구성되어 있다. (DI; dependency injection)

 

UML로 표현하면 다음과 같다.

 

[그림1] : [예제1] 코드의 UML

 

[그림2] : [예제2] 코드의 UML

 

[그림1]과 [그림2]는 각각 위 [예제1]과 [예제2]를 UML로 표현한 것이다.

 

- 그림1과 그림2의 차이

1) low coupling

그림1에서는 UserService 객체가 각각의 로그인 객체에 직접 적으로 의존해 2개의 의존도를 갖는다고 가정한다면, 그림2에서는 추상형 Login 인터페이스를 중간에 위치시킴으로써 UserService 객체는 1개의 의존도로 줄어들었다. 객체 간 의존도를 낮게해야 추후 코드변경 가능성을 줄여 유지보수에 용이하게 한다.

 

2) Dependency Inversion Principle (SOLID 원칙)

Login객체가 UserService객체에 의존하게 함으로써(화살표 방향이 반대가 됨) Dependency Inversion이 적용되었다. 역시 의존성을 역전시킴으로써 객체 간 결합도를 낮추는 효과를 얻을 수 있었다.

 

의존성이 높다면 이해하고 수정하는데 비용이 커진다. 따라서 객체 간 의존성을 낮춰서 관리포인트를 하나로 만들어 유지보수성 향상시킨다.