클래스는 객체를 찍어내는 형틀이다. 한번만 잘 정의해두면 얼마든지 많은 객체들을 손쉽게 찍어낼 수 있으며 그래서 생산성이 높다고 한다. 객체 지향의 생산성을 더욱 높이는 특징이 클래스로부터 좀 더 확장된 클래스를 만들 수 있는 상속이다. 상속에 의해 비슷 비슷한 코드가 통합되며 코드의 관리가 쉬워진다. 또한 객체 지향의 가장 큰 위력인 다형성도 상속을 기반으로 한다.
상속은 이미 만들어 놓은 클래스의 모든 멤버를 물려 받아 새로운 클래스를 정의하는 기법이다. 상속을 해 주는 클래스를 슈퍼 클래스라고 하며 상속을 받아 새로 만들어지는 클래스를 서브 클래스라고 한다. C++에서는 슈퍼 클래스를 부모라고 하며 서브 클래스를 자식이라고 하는데 같은 용어이다. 자바에서도 단어가 더 짧기 때문에 부모, 자식이라는 용어를 흔하게 사용한다. 자바의 상속 구문은 다음과 같다.
class 서브 extends 슈퍼 {
추가 멤버
}
키워드 extends 다음에 슈퍼 클래스를 적는다. 의미상으로 슈퍼 클래스를 확장하여 서브 클래스를 정의한다는 뜻이다. 서브 클래스는 슈퍼 클래스의 모든 멤버를 물려 받는다. 단, 생성자만은 예외적으로 상속되지 않는다. 일단 상속받은 후 추가로 더 필요한 멤버를 선언하거나 상속받은 멤버의 동작을 수정할 수도 있다. 다음 예제를 보자.
class Car {
public String Name;
protected String Color;
boolean Gasoline;
Car(String aName, String aColor, boolean aGasoline) {
Name = aName;
Color = aColor;
Gasoline = aGasoline;
}
void Run() {
if (Gasoline) {
System.out.println("부릉 부릉");
} else {
System.out.println("덜컹 덜컹");
}
}
void Stop() {
System.out.println("끼이익");
}
}
class Truck extends Car {
int Ton;
Truck(String aName, String aColor, boolean aGasoline, int aTon) {
super(aName,aColor,aGasoline);
Ton = aTon;
}
void Run() {
System.out.println("우당탕 쿵탕");
}
void Convey() {
System.out.println("짐을 실어 나른다.");
}
}
class JavaExam {
public static void main(String args[]) {
Truck Porter = new Truck("포터", "흰색", false, 1000);
Porter.Run();
Porter.Convey();
}
}
앞에서 정의한 Car 클래스로부터 좀 더 많은 특성을 가지는 Truck 클래스를 파생시켰다. 트럭은 자동차의 일종이므로 자동차의 모든 특성을 물려받는다. 이름, 색상을 가지며 달릴 수도 있고 멈출 수도 있다. 여기에 적재 가능한 톤을 의미하는 Ton 필드를 추가로 가지며 짐을 실어 나르는 Convey 동작이 가능하다.
생성자는 상속되지 않으므로 서브 클래스가 직접 정의해야 한다. 이때 부모로부터 물려받은 멤버는 직접 초기화할 수 없으므로 부모의 생성자를 호출하여 초기화를 위임한다. 슈퍼의 생성자를 호출할 때는 super 키워드를 사용하며 괄호안에 초기화할 인수를 전달한다. Truck은 네 개의 인수를 받아 이 중 물려받은 세 개를 Car 클래스의 생성자로 넘기고 나머지 하나를 자신이 직접 초기화한다.
서브 클래스가 제대로 동작하기 위해서는 부모로부터 물려받은 멤버가 제대로 초기화되어 있어야 한다. 그래서 서브의 생성자에서 슈퍼의 생성자를 호출하는 super 호출문은 생성자의 반드시 처음에 와야 한다. 다음처럼 순서를 바꾸면 컴파일 에러로 처리된다.
Truck(String aName, String aColor, boolean aGasoline, int aTon) {
Ton = aTon;
super(aName,aColor,aGasoline);
}
전달받은 인수를 super의 생성자에게 꼭 그대로 전달할 필요는 없다. 일부는 수정해서 전달 가능하며 아예 인수로 받지 않아도 상관없다. 다음 생성자도 가능하다. 트럭은 통상 경유를 연료로 사용하므로 연료 종류를 무조건 false로 초기화했다. 연료 종류는 생성자의 인수로 전달받지도 않으며 객체 생성문에서도 당연히 연료 종류를 지정할 필요가 없다.
Truck(String aName, String aColor, int aTon) {
super(aName,aColor,false);
Ton = aTon;
}
서브 클래스의 생성자에서 super의 생성자를 호출하지 않으면 디폴트 생성자가 자동으로 호출된다. 만약 슈퍼 클래스에 디폴트 생성자가 없다면 상속받은 멤버들이 제대로 초기화되지 않을 것이므로 에러 처리된다. 쓰레기값을 가질 수는 없으므로 어떤 식으로든 멤버들은 초기화되어야 한다.
서브는 슈퍼의 메서드를 그대로 상속받으므로 슈퍼의 동작 방식을 일단은 따른다. 그러나 슈퍼의 메서드와 다르게 동작하고 싶다면 메서드를 재정의(Override)한다. 재정의란 슈퍼의 메서드와 동일한 이름의 메서드를 서브에 또 정의하는 것이다.
위 예에서 Car는 Run과 Stop 메서드를 Truck에게 물려준다. 어떤 자동차나 멈추는 동작은 거의 비슷하므로 Stop 메서드는 상속받은 것을 그대로 사용하되 달리는 방식은 조금 다를 수 있으므로 Run 메서드는 재정의했다. 부모의 Run 메서드와 똑같은 이름으로 자식이 메서드를 또 정의하면 된다. 트럭은 아무래도 일반적인 자동차보다는 좀 더 시끄럽기 마련이다.
메서드가 재정의되면 슈퍼 클래스의 메서드가 아닌 재정의된 메서드가 대신 호출된다. 재정의된 메서드내에서 원래의 메서드를 호출하려면 super 키워드로 원래 메서드를 호출하면 된다. 재정의에 의해 동작이 완전히 바뀌는 것이 아니라 원래 동작에 다른 동작을 추가하고 싶을 때 이 기법을 사용한다. 다음과 같이 수정해 보자.
void Run() {
super.Run();
System.out.println("우당탕 쿵탕");
}
super의 Run 메서드가 먼저 호출되므로 연료 종류에 따라 달리는 소리를 먼저 낸 후 트럭의 고유한 소리를 또 낸다. 원래 메서드의 동작에다 추가 동작을 더하는 것이다. 이때는 생성자와 달리 super의 메서드 호출이 반드시 처음에 올 필요는 없다. 서브 클래스가 하고 싶은 동작을 먼저 한 후 슈퍼 클래스의 메서드를 호출할 수도 있다. 뒤에 호출할 수도 있고 중간에 호출할 수도 있으며 심지어 여러번 호출할 수도 있다.
void Run() {
System.out.println("우당탕 쿵탕");
super.Run();
}
슈퍼의 메서드는 재정의된 메서드에 의해 잠시 가려져 있다 뿐이지 일반적인 메서드와 다를 바 없으므로 필요할 때 언제든지 호출하면 된다. 별 실용성은 없지만 Convey에서 super.Run()을 호출하는 것도 물론 가능하다. 메서드 호출 문법에만 맞으면 된다.
메서드를 재정의하듯이 필드도 재정의할 수 있다. 슈퍼로부터 물려받은 필드의 타입이 마음에 안든다면 다른 타입으로 다시 선언하면 된다. 필드의 재정의 기법은 실용성이 높지 않지만 억지로 예를 들 수는 있다. 예를 들어 Car 클래스의 Color는 문자열인데 Truck에서는 RGB의 조합으로 색상을 표현할 수 있도록 정수로 재정의할 수 있다.
class Truck extends Car {
int Ton;
int Color;
이렇게 선언하면 Car의 Color 필드는 가려지며 Truck 클래스에서 Color 명칭은 정수형으로 사용된다. 물론 Truck 내에서는 Color를 정수형으로 참조해야 한다. 만약 슈퍼의 가려진 필드를 액세스해야 한다면 super.Color로 액세스할 수 있다.
상속을 통해 객체 지향의 가장 큰 특징이라 할 수 있는 다형성이 성립한다. 다형성은 똑같은 호출문이 실제로는 다양한 형태로 동작하는 것이다. 객체 지향 입문자들에게 가장 어려운 개념인데 차근 차근 연구해 보자. 만약 아직 다형성을 잘 이해하지 못하고 있다면 C++ 문법서를 통해 다형성의 개념을 먼저 익히기를 권장한다. 자바의 메서드는 무조건 다형적으로 동작하기 때문에 편리하기는 하지만 다형성의 필요성을 실감하기에는 C++보다 좋지 못하다.
다형성이 성립하는 기초는 슈퍼 클래스 타입의 변수로 서브 클래스 타입의 객체를 가리킬 수 있다는 것이다. 말이 좀 긴데 간단하게 "부모는 자식을 가리킬 수 있다"라고 외워 두면 된다. 다음 예제를 보자. Car, Truck 클래스 선언문은 앞 예제와 동일하다.
class JavaExam {
public static void main(String args[]) {
Car MyCar = new Car("제네시스", "빨강", true);
Car YourCar = new Truck("봉고", "파랑", true, 1500);
MyCar.Run();
YourCar.Run();
}
}
Car 타입의 MyCar가 Car 객체인 제네시스를 대입받는 것은 너무나 당연하다. 그러나 Car 타입의 YourCar가 Truck 타입의 객체를 대입받는 것은 다소 이상해 보이는데 이것은 아주 정상적인 문법이다. 부모 타입의 YourCar 변수가 자식 타입의 객체 Truck을 대입받은 것이다.
이것이 가능하고 논리적으로 문제가 없는 이유는 자식 객체에는 부모가 가진 모든 멤버가 존재하기 때문이다. YourCar로 호출할 수 있는 Run, Stop 메서드는 트럭으로도 가능한 동작이다. 트럭은 일종의 자동차이며 따라서 잘 달리고 잘 멈춘다.
그러나 YourCar.Convey() 호출은 에러 처리되는데 Convey는 Car 클래스에 정의된 메서드가 아니기 때문이다. YourCar 변수는 Car 타입이므로 Car에 속한 멤버만 참조할 수 있다. 만약 YourCar로 Convey를 호출하고 싶었다면 Truck 타입으로 선언해야 한다. 부모는 자식을 가리킬 수 있지만 반대는 안된다. 왜 안되는지 다음 코드를 보자.
Truck MyTruck = new Car("제네시스", "빨강", true);
MyTruck.Run();
MyTruck.Stop();
MyTruck.Convey();
MyTruck는 Truck 타입이므로 이 변수로 Convey를 호출하는 것이 가능해야 한다. 그러나 자식 타입의 변수에 부모 타입의 객체를 대입하면 논리적으로 불가능한 동작을 수행할 위험이 있다. 제네시스는 차의 일종일 뿐이지 트럭은 아니므로 짐을 싣는 능력은 없다. 그래서 아예 대입이 허락되지 않는다.
그렇다면 부모가 자식을 가리키는 것은 어떤 장점이 있을까? 위 예제처럼 컴파일시에 변수의 타입을 분명히 알 수 있는 경우는 딱 맞는 타입으로 선언하면 된다. 그러나 실행시에 타입이 결정될 때는 일반적인 타입으로 객체를 받아야 한다. 대표적인 예가 메서드의 인수로 객체를 받을 때이다.
class JavaExam {
public static void TestCar(Car car) {
car.Run();
car.Stop();
}
public static void main(String args[]) {
Car MyCar = new Car("제네시스", "빨강", true);
Car YourCar = new Truck("봉고", "파랑", true, 1500);
TestCar(MyCar);
TestCar(YourCar);
}
}
이 예제의 TestCar 메서드는 인수로 전달받은 차가 제 성능을 발휘하는지를 테스트한다. 시운전을 하는 것에 비유할 수 있겠다. 차라는 것은 일단 달릴 수 있고 멈출 수 있어야 하므로 Run과 Stop을 호출해 본다. 시운전할 대상은 차의 일종이면 되므로 이 메서드는 인수로 Car 타입의 객체를 받는다. 짐을 잘 싣는가는 테스트 대상이 아니므로 Truck을 인수로 받지 않는다.
TestCar가 Car 타입을 받으므로 Car로부터 파생된 모든 객체를 다 테스트할 수 있다. 트럭뿐만 아니라 버스, 탱크로리, 트레일러, 심지어 똥차까지도 다 가능하다. 왜냐하면 모두 차의 일종이며 Run, Stop 메서드를 지원하기 때문이다. 만약 Car 타입으로 파생 클래스의 객체를 받을 수 없다면 TestCar, TestTruck, TestBus 같은 메서드를 일일이 만들어야 할 것이다. 시운전 항목에 짐을 잘 싣는지, 똥을 잘 푸는지도 포함되어 있다면 물론 그래야겠지만 일반적인 자동차를 대상으로 한다면 굳이 그럴 필요가 없는 것이다.
여기까지 "부모는 자식을 가리킬 수 있다"는 것을 설명했다. 그렇다면 자식을 가리키는 상태에서 어떤 메서드가 호출되는지를 살펴 보자. 위 예제의 실행 결과는 다음과 같다.
부릉 부릉
끼이익
우당탕 쿵탕
끼이익
MyCar나 YourCar나 Stop은 모두 Car에 정의된 메서드를 호출하므로 동작이 같다. 그러나 Run 메서드는 Car에 정의되어 있고 Truck에서 재정의했으므로 호출하는 객체에 따라 동작이 달라진다. 제네시스는 부릉 부릉이고 봉고는 우당탕 쿵탕이다. 이런 결과가 당연해 보일지 모르겠지만 내부적으로는 상당히 복잡하게 처리된다.
클래스 타입의 변수로부터 메서드를 호출하면 변수 자체의 타입을 따르는 것이 아니라 변수가 실제로 가리키는 객체의 타입을 따른다. TestCar 메서드의 인수 car가 Car 타입이라고 해서 Run 메서드가 무조건 Car.Run이 아니라 car에 어떤 타입의 객체가 전달되었는가에 따라 호출되는 함수가 달라진다는 뜻이다. car로 MyCar가 전달되면 Car.Run이 호출되고 YourCar가 전달되면 Truck.Run이 호출된다.
이렇게 되기 위해서는 car.Run() 이라는 호출문이 어떤 메서드를 호출할 것인가는 컴파일 타임에 결정되는 것이 아니라 런타임에 결정되어야 한다. 어떤 인수가 전달될지 컴파일할 때는 알 수 없으므로 미리 결정해 놓을 수 없으며 메서드가 호출되어 봐야 알 수 있다. 호출될 메서드를 실행시에 결정하는 방식을 늦은 바인딩 또는 동적 바인딩이라고 한다. 위 예제의 Run 메서드가 바로 동적 바인딩을 하는 것이다.
C++에도 이와 동일한 개념의 함수가 있는데 바로 가상 함수이다. 동적 바인딩을 해야 하는 함수 앞에 virtual 지정자를 붙여 가상 함수로 선언해야 한다. 그러나 자바의 경우는 다르다. 자바는 C++과 달리 모든 메서드가 무조건 가상이다. 따라서 가상 메서드라는 지정을 별도로 하지 않아도 된다. 이 점이 C++과 자바의 큰 차이점이다.
C++이 가상 함수에 대한 명시적인 지정을 요구하는 이유는 성능 때문이다. 가상 함수 테이블을 위한 메모리가 소모되고 함수를 호출할 때도 테이블을 뒤져 실제 호출할 번지를 찾는 속도상의 불이익이 발생한다. 그래서 동적 바인딩이 꼭 필요한 함수에 대해서만 가상 함수로 지정해야 하며 그렇지 않은 함수는 비가상으로 동작한다. 최대한의 성능을 끌어 내기 위해 함수의 동적 바인딩 여부를 개발자가 수동으로 선택하도록 되어 있다.
그러나 자바는 모든 메서드를 가상으로 선언하는데 이는 성능 대신 편의성과 안전성에 역점을 두겠다는 작전이다. 가상이어야 할 함수를 비가상으로 선언하면 오동작하지만 비가상이어도 될 함수를 가상으로 선언한다고 해서 문제가 생기지는 않는다. 자바는 약간의 성능 감소를 희생하더라도 개발자가 편한쪽으로 설계되어 있는 것이다. 다행히 가상 함수에 의한 성능상의 불이익은 사실상 무시해도 될 정도로 경미하다.
이 부분에서 자바와 C++의 철학상의 차이가 가장 명백하게 드러난다. C++은 자나 깨나 성능 위주이며 자바는 항상 성능보다 편의성, 안전성이 우선인 것이다. 좀 비관적으로 얘기하자면 C++은 워낙 성능이 좋아 동적 바인딩에 의한 성능상의 불이익이 크지만 자바는 원래부터 느려 터졌기 때문에 동적 바인딩에 의한 성능 감소가 상대적으로 작게 평가되는 것이다. 성능의 관점에서 본다면 역시 C++이 우위를 점하지만 현대적인 고성능 하드웨어 환경에서는 당연히 자바의 선택이 현명하다고 볼 수 있다.
부모는 자식을 가리킬 수 있지만 자식은 부모를 가리킬 수 없다. 이것은 당연한 원칙이다. 그러나 때로는 자식 타입의 변수가 부모 타입의 객체를 대입받아야 하는 경우도 있다. 다음 예제를 보자.
class JavaExam {
public static void main(String args[]) {
Car MyTruck = new Truck("봉고", "파랑", true, 1500);
Truck AnyTruck;
AnyTruck = MyTruck; // 에러 발생
AnyTruck.Convey();
}
}
MyTruck을 Car 타입으로 선언해 놓고 Truck 객체를 대입했는데 앞에서 알아 봤듯이 부모는 자식을 가리킬 수 있으므로 이 대입은 항상 가능하다. 이 상태에서 Truck 타입의 AnyTruck 변수를 선언해 놓고 MyTruck객체를 대입해 보았다. AnyTruck = MyTruck 대입문은 변수명으로만 보면 가능할 것 같지만 컴파일해 보면 에러 처리된다.
왜냐하면 MyTruck의 선언 타입이 부모인 Car이고 이 값을 대입받은 AnyTruck은 자식인 Truck 타입으로 선언되어 있기 때문이다. 자식 타입의 변수가 부모 타입의 객체를 가리키면 문제가 발생한다. Truck 타입의 AnyTruck으로 Convey를 호출하는 것은 당연히 합법적인데 AnyTruck이 가리키는 객체가 Car 타입이라면 이 동작을 처리할 수 없기 때문이다.
그러나 위 예제에서 비록 MyTruck은 Car 타입이지만 분명히 Truck 객체를 가리키고 있다. 따라서 AnyTruck에 대입해도 Convey가 무사히 실행될 것이다. 문제는 컴파일러가 MyTruck에 어떤 객체가 대입되었는지를 확인할 수 없기 때문에 딴지를 건다는 것이다. MyTruck은 변수이므로 실행중에 Car 서브 클래스의 모든 객체를 대입받을 수 있으므로 컴파일 중에 MyTruck이 어떤 변수를 가리킬지를 판단하는 것은 불가능하다.
컴파일러는 워낙 소심해서 조금이라도 위험할 가능성이 있는 모든 대입문을 에러 처리한다. 이럴 때는 개발자가 캐스트 연산자로 강제 캐스팅을 해야 한다. 코드를 다음과 같이 수정하면 무사히 잘 컴파일될 것이다.
AnyTruck = (Truck)MyTruck;
이 캐스팅은 MyTruck이 Truck 타입의 객체를 가리키고 있다는 것을 명시적으로 밝힘으로써 컴파일러에게 이상없으니 대입하라는 것을 지시한다. 객체에 대한 캐스트 연산자는 객체의 실제 타입을 변경하는 것이 아니라 대입 가능한 타입임을 컴파일러에게 알리기만 할 뿐이다. MyTruck은 비록 Car 타입으로 선언되었지만 분명히 Truck 객체를 가리키고 있음을 개발자가 확실히 알림으로써 컴파일러의 타입 체크를 잠시 무능화시키는 것이다. 만약 캐스트 연산자가 잘못 사용된 것이라면 그 결과는 치명적이다. 다음 코드를 보자.
Car Pride = new Car("프라이드", "빨강", true);
Truck AnyTruck;
AnyTruck = (Truck)Pride;
AnyTruck.Convey();
Pride는 Car 타입으로 선언되어 있으며 실제 대입받은 것도 Car 타입의 객체이다. 이 상황에서 AnyTruck에 Pride를 대입했는데 좌우의 타입이 분명히 맞지 않다. 하지만 컴파일러는 Pride 앞에 붙은 캐스트 연산자를 보고 이 대입이 가능하다고 판단하여 에러를 내지 않는다. 컴파일은 무사히 되지만 막상 실행해 보면 예외가 발생하며 제대로 실행되지 않는다.
Exception in thread "main" java.lang.ClassCastException: Car cannot be cast to Truck
at JavaExam.main(JavaExam.java:123)
Pride 객체에는 Convey 메서드가 없으므로 엉뚱한 번지로 점프를 하여 프로그램이 폭주해 버리는 것이다. 보다시피 캐스트 연산은 객체의 타입을 강제로 바꾸어 대입을 가능케 하지만 경우에 따라서는 상당히 위험할 수 있다.
객체의 타입을 안전하게 변경하려면 변수가 캐스팅하고자 하는 클래스 타입의 객체를 가리키고 있는지를 조사해야 한다. 타입을 조사하는 연산은 instanceof 연산자가 수행한다. 기본 형식은 다음과 같다. 좌변에 객체를 쓰고 우변에 타입을 쓴다.
객체 instanceof 클래스
객체가 클래스 타입이 맞으면 true를 리턴하는데 이때는 안전하므로 캐스팅을 해도 된다. false를 리턴하면 타입이 다르므로 캐스팅을 해서는 안된다. 이 연산자는 컴파일할 때 타입을 점검하는 것이 아니라 실행중에 객체의 타입을 점검하므로 항상 정확하다.
위에서 보인 예제 코드들은 상황이 좀 복잡해서 잘 실감이 나지 않으며 설명을 위해 의도적으로 타입을 다르게 선언하다 보니 좀 억지스러워 보이기도 한다. 사실 위 코드에서 MyTruck을 Truck 타입으로 선언하기만 하면 아무 문제가 없다. 바로 아래에서 사용할 객체를 굳이 부모 타입으로 선언할 이유가 없는 것이다. 그러나 메서드끼리 객체를 전달받을 때는 이런 상황이 자주 발생한다. 다음 예제는 좀 더 직관적이다.
class JavaExam {
public static void TestCar(Car car) {
car.Run();
car.Stop();
if (car instanceof Truck) {
Truck truck = (Truck)car;
truck.Convey();
}
}
public static void main(String args[]) {
Car[] arCar = {
new Car("그랜저", "검정", true),
new Truck("포터", "파랑", false, 1500),
new Car("소나타", "하양", true),
};
for (Car car: arCar) {
TestCar(car);
}
}
}
arCar 배열은 자동차 객체의 집합을 저장한다. 이 배열에 Car 클래스로부터 파생되는 트럭, 버스, 택시, 탱크로리 등등의 모든 객체들을 다 저장해하므로 최상위 타입인 Car 클래스 타입이어야 한다. 이 예제에는 비록 Car 서브 클래스가 하나 밖에 없지만 실제 예에서는 아주 많아질 수 있다. 배열에는 Car 객체와 Truck 객체를 생성해서 초기화했다. 그랜저나 소나타뿐만 아니라 포터도 분명히 자동차 이므로 arCar 배열에 저장할 수 있음은 당연하다.
이 상태에서 배열에 저장된 모든 자동차들을 시운전해 본다고 해 보자. TestCar 메서드는 일반적인 자동차를 전달받아야 하므로 인수 car의 타입은 당연히 Car이며 이 인수로 Car 객체는 물론이고 Truck 객체도 대입받을 수 있다. 여기서 변수와 대입되는 객체의 타입 불일치가 발생하는 것이다. TestCar는 일단 Run, Stop을 호출하여 잘 가는지, 잘 서는지를 테스트하는데 이 두 메서드는 Car 소속이므로 모든 자동차가 지원한다.
다음은 트럭인 경우에 한해 짐을 잘 실어 나르는지도 같이 테스트해 본다. 이때 car의 Convey 메서드를 무작정 호출해 버리면 안된다. car가 Car 객체를 가리킬 수도 있고 Truck 객체를 가리킬 수도 있는데 인수로 전달된 객체가 Truck의 일종일 때만 Convey를 호출해야 한다. 이 판단을 바로 instanceof 연산자가 수행하는 것이다. car가 Truck의 객체이면 car를 (Truck) 타입으로 안전하게 캐스팅하여 Truck 타입의 truck 변수에 대입할 수 있다. 그리고 Convey를 호출하면 된다. 임시 객체에 대입받는 것이 귀찮다면 캐스팅한 후 바로 호출해도 상관없다.
((Truck)car).Convey();
car를 Truck으로 캐스팅한 후 Convey를 바로 호출할 것이다. 이때 . 연산자가 캐스트 연산자보다 우선 순위가 높으므로 캐스트 연산식을 괄호로 싸서 캐스팅을 먼저 수행한 후 멤버를 찾아야 한다. TestCar 메서드는 모든 자동차를 테스트하되 전달된 자동차가 트럭이면 짐을 잘 싣는지도 테스트한다. 만약 실행중에 객체의 타입을 판별하는 방법이 없다면 TestCar, TestTruck 함수를 따로 만들어야 할 것이다.
instanceof 연산자가 수행하는 연산은 객체의 동적 타입을 조사하는 것이다. 이 연산이 가능하기 위해서는 객체안에 자신의 타입이 무엇인지를 기억하는 정보가 따로 저장되어 있어야 한다. 즉, 별도의 메모리가 더 들어가야 하는 기능이다. C++에도 RTTI라는 동일한 기능이 있는데 메모리가 소모되는 기능이기 때문에 컴파일러의 옵션으로 선택하도록 되어 있으며 디폴트로 이 기능은 선택되어 있지 않다.
그래서 C++은 기본적으로 동적 타입 점검이 불가능하며 옵션을 켜야만 이 기능을 쓸 수 있다. 반면 자바는 디폴트로 동적 타입 점검을 지원한다. 이런 차이점이 발생하는 이유도 역시 성능 때문이다. C++은 성능에 조금이라도 불이익이 발생하는 기능은 일단은 회피해 놓고 개발자가 필요할 때만 쓸 수 있도록 하는데 비해 자바는 조금이라도 필요한 기능은 성능의 감수를 희생하고라도 무조건 제공한다.
앞에서 final 키워드는 상수 필드를 선언할 때 사용한다고 했다. 필드 선언문앞에 final을 붙이면 마지막으로 한번만 초기화하고 앞으로 더 이상 값을 바꾸지 않겠다는 뜻이므로 의미상으로 final이 적합하다. final은 필드 뿐만 아니라 클래스나 메서드에도 붙일 수 있는데 대상에 따라 의미가 조금씩 달라진다.
final을 클래스앞에 붙이면 더 이상 파생을 할 수 없는 클래스라는 뜻이다. 즉 상속에 의해 만들어진 마지막 클래스라는 뜻인데 클래스 계층의 제일 끝 부분에 존재한다. 너무 완벽하거나 너무 간단한 클래스에 대해 final을 붙여 상속을 금지한다. 또는 상업적인 이유로 final을 붙이기도 하는데 제 3 자가 클래스를 마음대로 확장해서 쓸 수 있도록 해 버리면 업그레이드된 버전을 팔아먹을 수 없기 때문이다.
final을 메서드 앞에 붙이면 더 이상 재정의할 수 없는 메서드라는 뜻이다. 메서드의 동작이 굉장히 복잡해서 함부로 재정의할 수 없도록 하고 싶을 때 이 지정자를 붙인다. 실력없는 띨띨한 개발자가 부주의하게 재정의를 하도록 내 버려 두면 원치않는 부작용이 나타날 수도 있으므로 아예 재정의를 금지해 버리는 것이다. final 메서드는 서브 클래스에서 동작을 수정할 수 없으며 애초에 슈퍼 클래스가 정의해 놓은 대로 호출만 할 수 있다.