Java 3.0이 필요한 10가지 이유

소리소문 없이 1.4가 나왔습니다. 웹사이트 관리 정말 못하는 군요 ㅡ.ㅡ;;

idiocy : 멍청한 부분 => 이게 어때서요?

저 또한 Java가 Objective-C 와 같이 Dynamic Type Checking이 되었으면 좋겠다고 생각하기도 합니다. 반대로 C++처럼 Generic Programming이 되는 것도 좋다고 생각합니다. 어느 쪽이건 분명해지는 것이 좋을 것 같습니다. 지금의 Java는 이것도 아니고 저것도 아닌, 뭔가 상당히 애매하다는 느낌입니다.

C++에서는 상속을 이용하는 경우와 template을 이용하는 경우를 분명하게 구별합니다. (이것을 제대로 구별하지 못하면 C++ 개발자라고 할 수 없습니다.) 반면 Java에서는 이 모든 것을 class 상속과 interface를 이용해서 해결해야 합니다. 그러나 이것만으로는 template을 깔끔하게 대체할 수 없습니다. 그 때문에 type casting을 이용해야 합니다.

여기에서 문제(제가 느끼기에는 그렇습니다)가 발생합니다. 상속만으로는 type 자체가 대체되는 것을 제대로 표현할 수 없으므로 type casting을 사용하지만, 정작 컴파일러는 이 typecasting이 유효한 것인지 아닌지를 검사하지 못합니다. 결국 type checking은 run time에서 수행해야 합니다.

그러나 run time에 check하도록 되어 있는 것도 아닙니다. 그러면서도 compile time에 type checking을 '엄격하게' 수행하기 때문입니다. 그 때문에 일일이 (type)expr 형식으로 type을 지정해 주어야 합니다. 즉 compile time도, run time도 type checking의 주요한 부분을 담당하지 못하고, 엉뚱하게도 coding time(이런 말은 없겠지만)에 type checking의 가장 중요한 부분을 수행해야 하는 셈이 됩니다.

공연히 글이 길어진 것 같은데, 결론을 말하자면 이렇습니다. 손으로 type casting 을 일일이 해야 하기 때문에 type 문제를 run time에 처리하는 경우의 편의성도 제공받지 못하고, 또 손으로 type casting을 해 준 것이 안전한지를 compile time에 확인하지도 못하기 때문에 type문제를 compile time에 처리하는 경우의 안전성 역시 보장받지 못하는 것입니다.

좋게 보면 절충이라고 할 수 있을지도 모르지만...적어도 손으로 typecasting을 해 주는 것이 C++의 Generic Programming의 경우보다 편하다고는 생각되지 않습니다. Objective-C의 경우와 비교해서 안전한지는...그 쪽으로는 경험이 부족해서 잘 모르겠습니다.

어느 쪽이건 확실하게 해야 한다고 생각합니다. 일단 발표된 내용으로 보면 Genenric Programming 쪽으로 가려는 것 같군요.

요즘 언어들은 컴파일러가 형검사들 통해 문제를 발견하도록 강한 Type checking을 하고자 하는 것이 전반적인 추세입니다. 소위 Type Safty라는 것인데, 이것은 생각보다 중요한 역할을 합니다. 뭐 코딩 잘못해서(소위 Type 잘못 넘겨서) Bug가 생기면 전적으로 프로그래머 책임이겠습니다만 그런 것을 찾아내는 역할을 컴파일러가 대신 해주겠다는 것이죠. 좋은 세상이니 너무 비관적으로 생각할 이유는 없습니다.

그리고 (String)a.getObject() 처럼 쓰는 이유가 있습니다.

a가 이미 String Type라고 해서 a.getObject()가 뽑아내는 타입이 String이라고 단정짓기는 어렵습니다.

만약 이 method가 Base Class에 속해 있고 Base Class에서 파생된 모든 자손들에게 상속이 되었다면 getObject()가 리턴하는 참조 포인터(&)는 Base Class의 포인터입니다. 이 경우에는 반드시 String으로 캐스팅해야하지요.

만약 이 method가 Base Class에 virtual 선언되어 있고 Base Class에서 파생된 모든 자손 Class에서 override된다면 굳이 Casting을 할 필요는 없지요.

getObject()같은 method는, Base에 하나 만들고 상속을 하든, virtual로 하고 각 파생 클래스에서 override하든, 둘 모두 일리있습니다.

어떻든 Class 체계가 전자와 같이 이루어 졌다면 캐스팅 반드시 해야하고 후자와 같이 이루어졌다면 캐스팅안해도됩니다.

근데 후자로 클래스를 구성하지 않았을듯합니다. 이유는 이러합니다.
만약 String을 상속받아서 새로운 클래스를 구성한다고 합시다. 그러면 상속받은 클래스에서 getObject() method를 Overrdie해야하는데 즉 다시 함수를 만들어 하는데, 귀찮은건 둘째 치더라도, getObject()가 반환하는 값이 정직해야하는데 프로그래머가 엉뚱하게도 다른 클래스(상속 관계도 없는)의 참조 포인터를 반환하게 했다면 Type Safty가 파괴되는 중대한 사태를 초래하겠지요.

다시 전자로 가서, Base Class에 있는 getObject() method를 파생 Class 모두와 공유하게 된다면 최소한 Base Class에 대한 포인터 값으로 Base Class에서 파생된 모든 Class를 표현할 수 있다라는 장점이있죠. 물론 사용할때 Casting을 해야한다라는 또 다른 작업을 해야하기는 하지만.

본인의 생각으로는 전자가 Type Safty의 측면에서 훨씬 나아보입니다. 후자는 OOP의 역할에 더 충실하군요.

그리고 String은 Class입니다. int도 Class입니다. 물론 C++에서.
또한 C++에서 int는 더 이상 C의 int도 아닙니다. 이것도 클래스입니다.

글쎄요... 제 생각에 동적/정적인 형검사의 선택은 언어의 사상에 따라 좌우된다고 생각합니다. 자바의 특성상 무엇보다 type-safety를 우선으로 생각하기 때문에 어쩔 수 없는 선택이 아니었을까요? generics가 논의되는 가장 중요한 이유도 오히려 컬렉션 등을 사용할 때 컴파일 타임에 형검사를 가능하게 하는 것이니까요.