[Java] Covariant(공변성)에 관한 간단한 이야기

📝 객체지향 5원칙(SOLID)

 SOLID는 객체지향 5원칙의 두음을 따서 만든 말이다. 각각 나열하자면,

• SRP(단일 책임 원칙)
• OCP(개방 폐쇄 원칙)
• LSP(리스코프 치환 원칙)
• ISP(인터페이스 분리 원칙)
• DIP(의존관계 역전 원칙)

위와 같이 존재한다. 이 중 오늘 이야기할 Covariant(이하 공변성)에 관한 이야기가 속한 곳은 LSP(Liskov Substitution Principle)다.

📌 LSP란?

 LSP는 타입 S가 타입 T의 서브타입이라면 프로그램의 속성 변경 없이 T타입의 객체를 S타입으로 치환할 수 있어야 한다.라는 개념이다. 쉽게 말하면, 서브타입은 수퍼타입을 대체할 수 있어야 한다는 말이다.

 서브타입이 수퍼타입을 대체하는 개념, 그것이 바로 공변성이다. 공변성을 이용한 프로그래밍의 장점에는 크게(?) 3가지가 존재한다.

1. 다형성 구현
2. 안정성 확보
3. 불필요한 소스 코드 절약 (타입 캐스팅)

 이해를 돕기 위한 예제를 보자. 클래스가 총 4개지만, 구현된 소스코드가 간단하니 이해하기 어렵지는 않을 거다.

public class A {
    I method() {
        System.out.println("A");
        return new I();
    }
}

public class B extends A{
    J method() {
        System.out.println("B");
        return new J();
    }

    public static void test() {
        A a = new B();
        a.method();
    }

    public static void main(String[] args) {
        B.test();
    }
}

public class I {
}

public class J {
}

 위와 같은 소스 코드에서 B class의 main 메서드를 run하면 나오는 값은 무엇일까?

java: method() in B cannot override method() in A
  return type J is not compatible with I

 위와 같은 에러가 발생한다. 해석하면, B에 있는 메서드는 A에 있는 메서드를 오버라이드 할 수 없다.
그 이유는 J타입은 I타입과 호환되지 않기 때문이다.

 자, 이제 에러를 해결하려면 무엇이 필요한가? I와 J의 관계를 설정해주면 된다.

public class J extends I {
}

 위와 같이 J를 I로부터 상속받는 클래스로 만들면 더 이상 문제가 없다. 왜냐하면, J는 I를 완벽하게 대체할 수 있기 때문이다.(LSP 원칙) 그렇다면, 아래와 같은 예제는 어떤가? 아래 4개의 메서드 중 어떤 것이 잘못된 것인지 알 수 있다면, 당신은 공변성을 이해했다.

public class B extends A{
    J method() {
        System.out.println("B");
        return new J();
    }

    public static I one() {
        A a = new B();
        return a.method(); // return I
    }

    public static I two() {
        B b = new B();
        return b.method(); // return J
    }

    public static J three() {
        A a = new B();
        return a.method(); // return I
    }

    public static J four() {
        B b = new B();
        return b.method(); // return J
    }

    public static void main(String[] args) {
        B.one();
        B.two();
        B.three();
        B.four();
    }
}

 

 정답은 3번 three() 메서드가 에러가 발생한다. 그 이유는 주석에도 보이듯이 J 타입을 반환해야 하는 메서드에서 a.method()는 I 타입을 반환하기 때문이다.

 여기서 하나 짚고 넘어가야하는 것은 LSP는 공변성을 인정하지, 역공변성은 인정하지 않는다. 즉, 수퍼타입은 서브타입을 완전히 대체할 필요가 없다. 즉, I를 상속받는 J는 J가 I타입과 같다고 봐도 무방하지만, I가 J타입과 같다고는 볼 수 없다.

 이는 동물에 비유하면 쉽다. 동물과 호랑이 클래스가 있다고 가정하자. 호랑이는 동물인가? 그렇다. 그렇다면, 동물은 호랑이인가? 이 말은 분명한 모순이 있다. 동물은 호랑이도 될 수 있지만, 다른 동물도 될 수 있기 때문이다. 역공변성을 인정하지 않는 것은 이 예시로 설명이 된다. J는 I에 속해 있지만, I는 J가 될 수도 있고 다른 것이 될 수도 있기 때문에 딱 지정할 수 없다.

 또한, three메서드를 보면 분명히 B 생성자를 통해 객체를 생성했는데 왜 J가 아닌 I를 리턴하는지 궁금할 수 있다. 이것은 생성자보다 변수의 타입이 더 중요한데, 변수의 타입이 A이기 때문에 A에서 생성된 리턴값을 반환하기 때문이다. (그런데, 프린트 값에는 B가 찍히는데, 이것에 대한 정확한 이유는 모르겠다. 다만, 현재 나는 객체가 리턴하는 값과 단순한 로직을 처리하는 프린트문은 서로 처리되는 순서가 달라서 발생하는 것이라고 생각하고 있다.) ps. 혹시 정확한 이유를 알고 계시다면 댓글을 부탁드립니다.

 여하튼, three 메서드를 해결하는 방법 중 하나는 타입 캐스팅이 있다. return a.method(); 앞에 (J)를 붙여주면 된다. 즉, return (J)a.method();가 되는 것이다. 그렇게 하면 반환하는 값이 (J)로 타입 캐스팅이 되게 된다. 다만, 이렇게 타입 캐스팅이 난무하게 되면 개발자가 실수를 했을 때, 오류를 잡기가 어렵다. 그 이유는 공변성에 의한 타입 캐스팅은 컴파일 에러를 반환하기 때문에 소스 코드 자체에서 에러 내용이 보이고, 프로그램이 동작하지 않지만, 일반적인 타입 캐스팅에 의한 실수는 런타임 에러를 반환하는 경우가 대부분이라서 에러 내용을 찾기도 어렵고, 프로그램이 동작한 후에 에러가 발생하게 되어 상당한 위험이 있다.

 그러므로, 객체지향 언어에서는 대부분의 경우에서 LSP(리스코프 치환 원칙)에 의한 코딩을 지향하는 바이다.